Срыв сроков и выход за оценки — довольно частая и болезненная проблема бизнеса при взаимодействии с IT-специалистами. Иногда срывы сроков и выходы за оценки начинают приобретать хронический характер и встаёт острый вопрос: «Что же с этим делать?».
Давайте рассмотрим, какие действия могут предпринять «неайтишники», чтобы выйти из ситуации. Сразу скажу, что слова: «Просто напишите нормальное ТЗ» — не прозвучат.
Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом) .
Я не пишу продающие тексты и не являюсь копирайтером, в конце статьи не будет коммерческого предложения и призыва к действию. Мне более интересно делиться знаниями и опытом. Некоторым людям мои статьи кажутся слишком длинными, если вам более привычен формат небольших сообщений, то обратите внимание на telegram-канал Записки ITBP.
Что обычно происходит, когда срываются сроки и превышаются бюджеты? Исполнители начинают говорить о неверной либо неполной постановке задачи, о невозможности произвести точную оценку либо о внезапно вскрывшихся факторах, которые было невозможно учесть заранее. Иногда могут прозвучать слова про частые изменения в постановке задачи и доработки, о которых не было известно на момент оценки.
Несомненно, хорошая постановка задачи очень важна. Если конечному исполнителю не описать, что вы хотите получить в результате, если сделать неправильную либо неполную постановку задачи, то результат получится неудовлетворительным.
Конечно, если исполнитель обладает не дюжей интуицией, которая позволяет угадывать, что хочет заказчик, который сам не знает, чего хочет, то может быть и получится. Либо если у разработчика есть большой опыт в своей прикладной области, из-за чего он лучше заказчика знает, что ему нужно, то тоже может получится.
Однако строить свою работу в надежде на то, что исполнитель — это не только IT-специалист, но он ещё разбирается в вашей бизнес-области лучше, чем вы, неправильно. Надеяться, что исполнитель как-то сам там на месте разберётся, тоже неправильно.
С другой стороны, бизнес-заказчик не является техническим специалистом, поэтому он может сделать лишь бизнес-постановку задачи. Сомнительно требовать от представителя бизнеса «написать нормально ТЗ» (ТЗ — техническое задание) . Обычно написать «нормально ТЗ» заказчику помогают бизнес-аналитики, системные-аналитики, руководители проектов. Если бизнес-заказчику предлагается сделать всё собственноручно, то явно что-то идёт не так.
То есть процесс управления требованиями и изменениями, который существует в области информационных технологий, может ломаться как в самом начале, на уровне бизнес-заказчика, так и в конце, на уровне конечных исполнителей. В середине он тоже может сломаться, например, из-за неверно произведённого системного анализа.
Поэтому имеет смысл пройти всю цепочку от начала до конца. При этом стоит воспользоваться тем, что первые звенья цепи задают условия работы для последующих звеньев. На самом деле, находясь в начале цепочки, не так уж сложно управлять всем процессом целиком.
Прежде давайте всё же посмотрим, а что такое ТЗ на самом деле и зачем оно вообще нужно?
Техническое задание
Это документ или несколько документов, определяющих цель, структуру, свойства и методы какого-либо проекта, и исключающих двусмысленное толкование различными исполнителями. Иными словами, документ определяет не только что нужно получить, но и как это сделать.
Для интереса берём ГОСТ 19.201-78 «Техническое задание. Требование к содержанию и оформлению», там написано, что техническое задание должно содержать разделы:
введение (краткую характеристику области и реализуемого программного обеспечения) ;
основания для разработки (ссылка на документы основания для разработки, нужно для крупных организаций) ;
назначение разработки (для решения каких задач мы это делаем) ;
требования к программе или программному изделию (выполняемые функции, временные характеристики, надёжность, инфраструктура и совместимость) ;
требования к программной документации;
технико-экономические показатели (должна быть экономическая целесообразность) ;
стадии и этапы разработки;
порядок контроля и приёмки;
в техническое задание допускается включать приложения.
В целом, видим, что с 1980-го года ничего кардинально не поменялось. Для описания структуры и формы ТЗ хватает 4-х листов. Различные формы для написания спецификации на программное обеспечение на сегодня общедоступны. Ценность представляет не какая-то стандартная форма, а умение наполнять её содержанием.
При реализации программного обеспечения проблемы возникают в местах, где кому-то что-то приходится додумывать либо возможны разные трактовки написанного. Если человеку дать возможность ошибиться, то он ей непременно воспользуется. Однако не стоит пытаться написать максимально подробное ТЗ. Если вы уже пишите в ТЗ алгоритмы и мета-код, наверное, программисты вам не нужны и вы уже можете всё сами. В этом случае, пора задуматься о замене программистов на низкоквалифицированных кодеров за минимальные деньги.
Разница между кодером и программистом заключается в том, что кодер умеет хорошо набирать код и может в совершенстве знать язык программирования, на котором работает, а программист умеет думать и эффективно решать задачи. Кодеру бывает нужен мета-код, программисту вряд ли.
Наша задача — управлять границами неопределённости при постановке задачи. То есть мы даём исполнителю возможность что-то додумать, где-то срезать углы, но не даём ему отклониться от плана реализации слишком далеко. Сильно погружаться в технологии и детали для этого не нужно. Для управления неопределённостью у нас есть два инструмента.
Первое, мы как представители бизнеса рассказываем, для чего будет использоваться программное обеспечение и как оно будет использоваться. То есть какой набор действий должен быть доступен пользователю в системе. Кроме этого мы рассказываем, какую бизнес-цель мы при этом себе ставим.
Второе, чем дольше что-то происходит, тем больше неустойчивости и неопределённости приобретает. Поэтому процесс реализации мы должны разбить на этапы, рассказать, что и на каком этапе мы ожидаем, а потом сказать, как мы это будем проверять. Чем короче интервалы разработки, тем меньше риск, что исполнители свернут куда-то не туда.
Самое интересное, что для управления процессом реализации погружаться в технические вопросы реализации зачастую нет необходимости.
В своей практике мы в качестве «технического задания» и «спецификации» используем последовательность документов:
Бизнес-требования. Изложение на бумаге от заказчика того, что он хочет получить от системы и особые требования к системе, которые у него есть.
Вижн (видение, представление) . Изложение на бумаге того, как мы услышали заказчика и как мы представили себе систему. Обычно это текст на 1-2 листа.
Функциональные требования. Перечисление основных функций в системе на несколько листов. Обычно именно функциональные требования включаются в договор.
Разбивка по этапам реализации. Тоже может включаться в договор.
Макеты приложения и описание пользовательских сценариев.
Если нужно, то архитектурная схема и схема потоков данных между интегрируемыми системами, иногда описание API (Application Programming Interface — формат общения с информационной системой для другой информационной системы).
Всё, кроме 6-го пункта, который обычно состоит из нескольких схем, может понять простой человек, не обладающий технической экспертизой. Примерно такой же логикой действий мы воспользуемся, чтобы восстановить контроль над ситуацией.
Ставим бизнес-цель
Прежде всего, вам необходимо описать ту бизнес-цель, которую вы преследуете, либо бизнес-задачу, которую вы хотите решить. Сильно утрируя, у вас не может быть бизнес-задачи типа «создать интернет-магазин», у вас может быть задача по организации новых каналов сбыта, увеличения продаж либо повышения выручки.
Та бизнес-цель либо бизнес-задача, что вы себе представите, будет маяком, на который будет ориентироваться вся команда разработки, включая вас, принимая решения: "А вот то, что мы сейчас делаем, оно вообще нужно?".
Например, в самом начале нашей деятельности к нам пришел заказчик и запросил оценить интернет-магазин. Причём им уже кто-то до этого пытался сделать какой-то интернет-магазин. В процессе разговора выяснилось, что это завод элитной мебели, которая распространяется через дилерские центры. И отбирать кусок хлеба у своих дилеров — плохая идея. Интернет-магазин нанёс бы вред бизнесу.
Однако, с какой-то периодичностью для дилеров печатались высококачественные бумажные каталоги, и это стоило больших денег. Решением стала разработка сайта-каталога, на котором сотрудник дилера мог оформить заказ. То есть человек приходил в дилерский центр, просматривал каталог на планшете (либо просто присылал дилеру свой виш-лист) , выбирал понравившуюся мебель, сотрудник дилера делал заказ и продолжал сопровождение клиента.
После реализации сайта-каталога продажи клиента выросли в несколько раз, то есть его бизнес-цель была достигнута. Не смотря на то, что форма достижения в процессе общения полностью изменилась.
Бизнес-цель либо бизнес-задача должны быть критерием сдачи «проекта» самому себе, как заказчику. После того как будет закончена разработка, проведено внедрение и получен опыт эксплуатации, вы должны будете себе честно ответить достигнута ли цель. А так же стоило ли достижение этой цели затраченных усилий.
Шаг кажется очевидным, но очень часто пропускается, что может иметь печальные последствия. Просто бесцельная реализация чего-то вряд ли будет успешной, не смотря на весь профессионализм технической команды.
Представляем себе систему
Как говорил Стивен Кови, мысленное творение предшествует физическому творению. Чтобы что-то создать в мире объективной реальности, вы должны это создать в своём воображении. Кроме шуток — нужно. А потом быть способным словами описать тот образ, который вы представили. Желательно письменно, на бумаге, чтобы не возникало ложного впечатления, что вы себе всё представили и уже можете это описывать.
При постановке задачи для IT-специалистов всё работает ровно так же. Если вы попробуете заказать произвести что-то, чего даже представить себе не можете, то результат вас поразит, но вряд ли это будет приятной неожиданностью.
Это тоже очевидный шаг, которым зря пренебрегают. Из-за этого часто бывает разочарование у заказчика, ведь если не знать, чего ты хочешь, то всегда будешь получать что-то не то.
Понятное дело, что бизнес-заказчик — не технический специалист, он не может представить, как система устроена внутри. Зато он может представить себе, как с нужной ему системой будут работать пользователи. Это позволит ему описать базовые пользовательские сценарии в системе.
Избыточно подробное описание образа системы в бизнес требованиях большого смысла не имеет. Надо передать понимание задачи, которую решает система, и основного сценария работы пользователей в системе. Остальное будет сделано при дальнейшей проработке задачи.
Нужно быть готовым к тому, что сформированный образ системы — это не что-то незыблемое и неизменное. Нет, в процессе обсуждения и разработки системы (по мере получения реального пользовательского опыта) образ будет меняться — это нормально. Попытка сразу сделать (представить систему) идеально — это плохой и вредный путь. Вы управляете неопределённостью, а не воюете с ней. Как это не странно, неопределённость может быть хорошим другом, а не только мешать.
Передаём образ системы
Вам нужно как-то передать сформированный образ системы команде разработки. Процесс передачи очень важен, в нём есть свои риски, часто первый говорит одно, а второй слышит (и даже читает) другое.
Ещё момент. Обратите внимание на того, кому вы пытаетесь передать образ. Если это программист, то надо напрячься. Скорее всего, что-то идёт не так. Есть разработчики, которые хорошо коммуницируют с заказчиками, понимают предметную область и могут подсказать правильные решения. Однако, чаще всего это не так. А даже если это и так, такие разработчики обычно быстро растут и покидают компанию.
Если у вас прямая связь с разработчиком и у вас всё работает, задачи делаются быстро, в срок и сразу то, что нужно, значит вам крупно повезло. Если нет, значит пора менять подход к процессу разработки. Всё же специализации бизнес-аналитиков, системных аналитиков, архитекторов, руководителей проектов и прочих появились не на пустом месте.
Конечно, можно переложить на программиста ответственность за решение бизнес-задач, в чём он не компетентен. В ответ он потом вас пошлёт писать правильное ТЗ, в чём будете некомпетентны уже вы. Так и будете ходить по кругу, пока кто-нибудь не сообразит, что дело не в вас двоих, а процесс разработки пора чинить на уровне отдела/департамента/дирекции, а не конкретного программиста.
Допустим, у нас всё работает правильно, и мы общаемся не с программистом, а с бизнес-аналитиком либо руководителем проекта. После рассказа о системе (либо чтения вашего письменного запроса) потребуйте вижн в ответ. То есть принимающая сторона садится и на один лист пишет то, как им представилась система, которую вы описали.
Вижн — важный инструмент проверки, что коммуникация произошла без сбоев и вы себе представляете что-то похожее.
По сформированному вижну запросите предварительную оценку. Вилку оценки можно давать навскидку. Помогает упражнение: «Сколько стоят женские сапоги?». На удивление, люди с ходу могут выдавать оценку стоимости женских сапог, не являясь профессиональными «сапожниками» и не являясь сотрудниками магазина женской обуви.
Но если вы вдруг работаете на предприятии по пошиву обуви, то себестоимость производства сапог (в общем, в среднем) вы назовёте ещё и очень точно. Оценка стоимости разработки программного обеспечения не сильно отличается от оценки разработки новой модели обуви, одежды и т. д.
Предварительная оценка — это второй инструмент проверки переданного образа. Если оценка сильно выше рыночной, то либо вы просмотрели какие-то подводные камни и вам должны о них рассказать, либо команда разработки в своём воображении переусложнила систему. Слишком низкая стоимость — аналогично, возможно команда разработки не учла какой-то подводный камень, теперь о нём должны рассказать уже вы.
Мы же, как бизнес-заказчик, достаточно умны, чтобы узнать, что и сколько стоит на рынке? И понимаем, что компания аутсорсер в цену заложит не только свою маржу, но и все риски и накладные? Даже наша компания, которая специализируется на заказной разработке, так иногда делает.
Если у вас появились вопросы к предварительной оценке, то попросите исполнителей рассказать последовательность действий, которые они будут выполнять при разработке и почему они так уверены в своей оценке. В процессе разговора вы произведёте детализацию образа системы и обменяетесь информацией о системе. После чего должна поменяться либо оценка либо ваше представление о системе.
Если оценка не меняется и не меняется ваше представление о системе, пройдитесь по рынку, пообщайтесь с людьми, которые специализируются на заказной разработке. Они ведь тоже могут рассказать что и как будут делать. В какой-то момент вы сможете понять в чём дело.
Проработка требования и разбивка на этапы
Допустим, что вы работаете над проектом, разработка которого занимает несколько календарных месяцев. Значит, вам необходимо проработать требования. Если написать вижн (видение системы) занимает 1-2 часа, предварительная оценка — 0.5-1 часа (это же простая рыночная статистика), то проработка требований — это целый длительный процесс. Точную оценку на проработку требований вы должны получить в момент формирования предварительной оценки системы в целом.
Как уже отмечалось, форм описаний спецификации программного обеспечения (технических заданий) множество. Но крайне желательно, чтобы они включали в себя описание пользовательских сценариев. То есть тех действий, которые должны будут сделать пользователи в системе, чтобы получить требуемый результат.
Вы же должны будете согласовать проработанную постановку задачи? Значит и вы, как нетехнический специалист, должны её понимать. Вряд ли вы до конца поймёте архитектурную схему, схему потоков данных, описание API и прочее. А пользовательские сценарии — поймёте.
Иногда при проработке требований создаются макеты приложений. То есть отрисовывается часть экранов, которые будут у приложения. И уже по ним либо вместе с ними пишутся пользовательские сценарии. Когда человек видит перед собой иллюстрации, ему гораздо проще детализировать образ системы, которую нужно разработать.
В любом случае, написание и согласование пользовательских сценариев, разработка макетов и прочих поясняющих схем и диаграмм — это часть работы по проектированию системы.
В ходе проектирования образ системы может меняться — это нормально. При проектировании может меняться и стоимость разработки системы — это тоже нормально. Поэтому всегда следите за бюджетом. Новые требования и вводные — новые строчки в итоговой смете.
На самом деле, хорошая команда проектирования умеет проектировать в бюджет. Вы им говорите, что есть столько-то денег, они вам предлагают какое-то решение, которое укладывается в бюджет и как-то приближает нас к бизнес-цели.
При проектировании необходимо представить себе поэтапную разработку приложения. Каждый этап должен включать в себя реализацию каких-то пользовательских сценариев целиком. Это важно.
К каждому этапу необходимо прописать критерии сдачи и сценарии, проверяя которые вы, как заказчик, убедитесь, что работа выполнена в полном (оптимистично, конечно) объёме.
По итогу реализации этапа команда разработки должна будет вам показать демонстрацию продукта, как раз по тем сценариям сдачи, что вы пропишете при проработке требований. Желательно, чтобы у вас потом была ещё возможность самому «потыкать» систему.
Длительность этапа не должна превышать нескольких месяцев. Чем длительней срок разработки, тем выше риски, что что-то пойдёт не так. Риски растут не линейно, а по параболе (для простоты) .
Вовремя проверяя ход работ, вы сохраняете себе возможность вернуть процесс разработки на корректный путь и минимизировать потери от того, что кто-то заблудился в процессе разработки.
Итогом проработки требований будет не только спецификация (техническое задание) , разбивка на этапы и критерии сдачи к ним, но ещё и смета. Вы должны знать, сколько стоит каждый этап.
Управляем рисками и собираем статистику
Хорошей идеей будет заложить бюджет по деньгам, ресурсам и срокам больше, чем в смете. Это на случай если что-то пойдёт не так. Просто заложите между этапами буфер в сколько-то процентов от стоимости этапа. Но никому и никогда не сообщайте о размере этого буфера и его существовании вообще.
Иногда делаются ошибки, сроки срываются. Бывает, что выясняется, что при проработке требований что-то было упущено и нужны дополнительные работы. Это изменения сметы, которые должны согласовываться с вами. Не согласованно — не оплачивается. Но если согласованно, то должен быть бюджет, из которого это можно оплатить.
Кроме того, вы сами, когда получите возможность «потестировать» сданные этапы, после приобретения пользовательского опыта, можете решить, что системе нужны доработки. И у вас будет бюджет на реализацию ваших доработок.
Важным показателем является отклонение фактических затрат от запланированных. Чем более часто и масштабней такое отклонение происходит, тем более тревожный это сигнал. Когда у вас на руках есть зафиксированные требования, разбивка по этапам и смета, проводить переговоры с отделом/департаментом/дирекцией разработки куда проще.
В крайнем случае вы можете получить рыночную оценку и ставить вопрос о замене исполнителей. Когда люди понимают, что и их можно заменить, вопрос лишь в стоимости замены, диалог начинает налаживаться.
Подводя итоги
Мы с вами рассмотрели последовательность действий, которую может выполнить нетехнический специалист. При её выполнении не нужно особых знаний технологий либо навыков управления людей. В чём-то последовательность этих действий напоминает то, что делает хороший руководитель проекта.
Конечно, чтобы быть хорошим руководителем проектов в IT, нужно разбираться в технологиях, координировать работу специалистов и управлять коммуникацией. Но суть работы всё равно будет заключаться в управлении образом системы в головах всех участников проекта и управлении поэтапной реализации образа.
Помним, что бизнес-заказчик — это тоже участник проекта. Он тоже выполняет работу над проектом, важную работу. А не только приходит за готовым результатом.
Кто-то может написать, что всё же и так понятно и очевидно. Зачем переливать из пустого в порожнее? На что можно ответить, что раз всё так понятно и очевидно, то почему так много людей пропускают эти этапы и делают ошибки?
Даже более того. На самом деле ровно те же проекты, что в разработке IT-проектов, возникают при постройке частного дома либо работе отделочной бригады. Проблемы возникают одни и те же. Часто возникают.
Ну а ещё, мы наконец-то узнали, что такое на самом деле «ТЗ» и почему просить написать «нормальное ТЗ» бизнес-заказчика — это плохая идея.
Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.
Полезные материалы по теме:
- IT для неайтишников: Зачем оно нужно?
- IT для неайтишников: Какими бывают IT-шники? Часть 1
- IT для неайтишников: Какими бывают IT-шники? Часть 2
- IT для неайтишников: Какими бывают IT-шники? Часть 3
- IT для неайтишников: Какими бывают IT-шники? Часть 4
- IT для неайтишников: Какими бывают IT-шники? Часть 5
- IT для неайтишников: Какими бывают IT-шники? Часть 6
- IT для неайтишников: Какими бывают IT-шники? Часть 7
- IT для неайтишников: Какими бывают IT-шники? Часть 8
- IT для неайтишников: Куда исчезают программисты после 40 лет?
- IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
- IT для неайтишников: Технический долг или почему теперь всё так долго?
- IT для неайтишников: Осторожно - JSDD (Бизнес в заложниках у IT)
- IT для неайтишников: Инженеры в заложниках у бизнеса
- Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
- Процессы в ИТ: Долго, дорого и не то
- Саморегуляция в ИТ: минимально допустимая эффективность работы
- Telegram-канал Записки ITBP (короткие сообщения)
- Канал на Дзен Записки ITBP (статьи среднего размера)
Если речь идет о стандартных проектах (магазины, лендинги, сайты компаний), то все проходит в основном гладко, ибо путь понятен и многократно пройден.
С нестандартными проектами заказчик, который не имеет возможность завалить программистов (назовем так компанию подрядчика) деньгами, даже с наиподробнейшим ТЗ, сталкивается и с увеличением сроков, и с увеличением смет. Со сроками ничего не поделаешь, по деньгам еще можно поторговаться, но не более того. И главная причина - шантаж. Программисты могут бросить (и нередко бросают) проект, когда считают, что он становится им невыгоден. А невыгодным он может стать по причине ошибок самих же программистов. Например неправильно поняли ТЗ. Признали это, исправили, но зарплаты за потраченное время все равно им платили и они списались из бюджета заказчика. И по факту на правильную реализацию остается меньше денег. А если заказчик начинает качать права, то ему говорят - ну ок, давайте остановим проект и разойдемся. И это может произойти спустя месяцы работы. То есть заказчик теряет предоплату (пусть и небольшую), время и должен все начинать с нуля. Нужно помнить, что начиная любой проект заказчик попадает в зависимость от порядчика, если у него нет возможности послать подрядчика, потеряв деньги, время и начать все с нуля. А если такая возможность есть, то нет гарантии, что новый подрядчик будет лучше прежнего.
Можно так легко съехать с обязательств? Есть же договор, в котором прописаны сроки и стоимость, подписан он с обеих сторон
В котором оговорены и условия расторжения.
Но не может же там быть "проект стал невыгоден"
В IT есть понятие «усталость кода» и «технический долг». Мы работаем в единой системе, в которой иногда можно сделать быстро и дешево либо дорого и правильно. Когда выбирают быстро и дешево, образуется «технический долг», займ у системы.
За технические долги постоянно идут проценты, то есть мало когда-нибудь исправить, растут накладные на разработку вообще. В какой-то момент может наступить «технический дефолт», когда стоимость внесения изменений в систему становится слишком высокой.
Вот в такой момент подрядчик может отказаться брать новые доработки, так как проект стал для него невыгодным. А новые подрядчики тоже отказываются ввязываться в такую авантюру.
Обычно же это не один договор, а целая их серия. Продукты живут, их нужно дорабатывать под вновь возникающие требования от изменяющейся жизни.
Есть договоры с этапами сдачи, можно просто не начинать следующие этапы. ГК РФ такое вполне позволяет, как и частичное выполнение договора с частичной его оплатой. Есть просто договоры по T&M.
Да - можно, но это не этично.
Правильно понимаю, что в айти поменять подрядчика куда сложнее, чем в, скажем так, реальном секторе?
Представьте себе, что вы начали строить многоэтажный дом и выбрали для этого подрядчика. На середине строительства вы поняли, что качество работы вас не устраивает. И может оказаться, что были допущены архитектурные ошибки, несущие конструкции сделаны из материалов с прочностью ниже проектной, а еще геологию участка никто не производил.
Вы можете поменять подрядчика, но есть риски, что весь дом придется сносить и стоить заново. Но в любом случае, нужен аудит и проработка плана действий, возможно что-то можно перестроить, где-то конструкцию усилить и отделаться «малой кровью».
Все очень индивидуально, но замена действительно не всегда простая.
P.S.
Плюс, IT-шники не строители, кучи нормативных требований они соблюдать не обязаны, гарантию в 5 лет не дают, правоприменительной практики очень мало.
Вот со строительством знаком как раз ближе. И там нерадивого подрядчика можно оставить без штанов, а пару человек и на нары присадить
Значит можете представить все то же самое, но без стандартов, нормативов и прочего. Плюс дефицит кадров и экспертизы на рынке. То есть оставить кого-то без штанов будет сложно.
Ну и если говорить о строителях, то они любят обновлять юридические лица. Конечно, подрядчиков нужно выбирать, но тем не менее и у строителей есть лазейки, но их много меньше.
Думаю, экспертизу все равно возможно провести и нагнуть горе-погромистов за невыполнение условий договора
Я тоже знаком и со строительстром и с разработкой. Одно с другим рядом не стояло. Когда подрядчик на стройке выполняет работу у него уже есть по факту пошаговое ТЗ с четкими критериями выполнения. У нас же разработчиков есть абстрактное ТЗ и хотелки. И даже то ТЗ котрое называют полным не всегда является таковым.
P.S. по стилю вашего написания сразу понятно что у вас все априори "горе-погромисты" "горе-подрядчики" и т.д., и в стоительстве я бы может с вами и сотрудничал, но в разработке обошел бы ща километр
Разработка не стандартизирована и не может таковой быть по сути своей и всегда имеет две медали. В заложниках может оказаться и заказчик и подрядчик. Я был по обе стороны.
А почему абстрактное? Из-за желания сэкономить? Отсутствия профессионалов? Отрасль же немолодая, а в ней какой-то хаос
не задумывались почему на тильде сайты копейки стоят? ... я вот по России не вижу прям глобального разнообразия в постройках ) аналогично и здесь - хотите меньше рисков, берите готовое или максимально близкое к хотелками, а так фактически запустить конвейер с 0, я не видел историй где что-то вовремя получилось сделать, в плане нового продуктов
поэтому все истории - мы делаем вовремя, когда проект новый для команды и здоровый - ну мягко говоря трындеж, либо там коэфициенты на сроки и стоимость космические
Сложно согласиться. Просто нужно использовать взрослые методики ведения проектов, а они сложные и требовательные к компетенциям руководителя проекта и архитектора.
И честно говоря, я уже слушать от кандидатов про Agile и Waterfall. Пятьдесят лет прошло, а воз и ныне там. Сравнивают итерационную модель продуктовой разработки с упрощенной абстракцией. При этом забывая, что Agile - это вообще манифест.
Agile - манифест "за всё хорошее против всего плохого", Scrum - распиаренный итеративный процесс, изначально расчитанный на быструю разработку маленького проекта маленькой командой, а Waterfall - мифический демон, с которым воюют лыцари аджайла :)
я написал про сроки и цену. Возьмите топ студий рейтиг рунета, там верстка начинается от ляма (понятно что туда входить может что угодно) Пример попроще - работал с компаниями у которых "вижен" на форму авторизации (простую) закладывали 200-300к и 40-80ч
я четко знал что будет и как, те съехать на то, что там помимо этого подразумевались еще какие то другие работы ну не выйдет. Выдержать сроки при таком раскладе как 2 пальца.
А так волшебной пилюли нет, но я бы все таки рекомендовал если нужен автомобиль, брать компании которые делают автомобили, а не тракторы или самолеты.
"Взрослые методики" - тут уже я не соглашусь, пока не увижу цифирки ) либо аутстафишь и продаешь часы как ебам, либо яросно перезакладываешь риски, ну или спасительные спринты, когда зона ответсвенности на неделю или 2. Тогда не договаривая можно гордо топить - мы вовремя делаем... спринты )
Вы берете студии разработки, а потом удивляетесь, что они не могут делать серьезные проекты. :о)
Вот мы любим работать по инкрементно-итерационной модели, а спринты не используем. Можно взять Unified Process, как пример методики разработки по инкрементно-итерационной модели. Можно делать сложные проекты быстрее и дешевле среднего по рынку.
При разработке сложной системе, как в беге, огромная часть затрат обычно приходится на ненужные действия и телодвижения. В частности отсюда и берется «долго, дорого и не то».
да они просто так называются в рейтинге, там интеграторы федеральные. можно, все что хочешь, но цифры есть цифры, а их нет ) было бы интересно посмотреть на нескольких итерациях для среднего по рынку проекта сколько вы насчитаете ))
Имея опыт работы с системными интеграторами, скорее всего где-то 30%-50% от цены, что они назовут.
Кстати, у вас интересное желание увидеть конкретные цифры под абстрактный проект. Выглядит, как нечестный прием ведения дискуссии. :о)
ну можно на примере реального - просто вдруг NDA
все работы складываются из мелких - взять для примера можно любую.
А так вы, говорите что можете любой проект взять, я топлю за специализацию, если ориентир сроки цена кач-во. Учитывая что тексты у вас хорошо получаются, доказать клиенту что цена будет средняя по рынку не составит труда. ) Но хотелось увидеть что такое "среднее" (что туда входит вроде уже написали). У интеграторов есть ценники, и там весьма благородно все риски учтены.
у меня некоторый опыт с большими игроками, там даже с 50% крайне замечательно выходит, были б это не гос конторы - меня бы ссаными тряпками коммерсы гнали за такие цены/сроки. А так, собственно то о чем я и говорил - есть очень хороший бюджет и сроки ну понятно что скорее всего все будет ок
Например, мы оценивали автоматизацию с применением IoT для одного дочернего предприятия для крупного региона РФ. Причем её нужно было сделать менее чем за год с импортозамещением существующей аппаратной базы. Мы были готовы сделать за 50КК, но правительству региона было удобней работать с системным интегратором, который за все по итогу возьмет где-то 180КК-200КК. На уровне министерства было решено, что так «безопаснее», не смотря на все попытки главы организации уйти от работы с системным интегратором, который точно провалит сроки.
ну на определенном этапе начинают работать не цены, а вот этот парень рыбалку хорошую устроил, не только у нас ) нетворкинг типа ))
а и да - ну если авторизация 200к (из моего примера) , как то можно унизиться за 100к за 2ч-3ч) я думаю
Чаще всего требуется уникальный продукт. Или хотя бы непохожий на остальные. Кроме того, во многих случаях заказчик хочет начать начать с минимально возможного продукта, чтобы проверить свои гипотезы. Грубо говоря, он не хочет ждать, пока будет достроен огромный торговый центр, а хочет вначале открыть маленький ларёк, который будет затем достраиваться до магазинчика, супермаркета и, наконец, многоэтажного торгового центра. Притом работать должен круглосуточно. Ну и да, планируется жилая зона в середине торгового зала, вертолётная площадка на первом этаже, зоопарк, цементный завод, бассейны на балконах и атомная электростанция.
Так в любой сфере часто проектируется что-то уникальное, но с оглядкой на нормативы, здравый смысл и целеобразность
Здравый смысл и целесообразность это немного не про современное IT. Про атомную электростанцию на балконе, это не совсем шутка....
А отчего так? Вроде же инженеры есть, технари
Так отрасль очень динамичная и непредсказуемая, обладает сложным нелинейным поведением. Конечно, с этим можно работать, но нужна теория детерминированного хаоса, а её не каждый математик поймет. :о)
Так она динамичная и непредсказуемая из-за чего? По факту, она ничем не отличается от иных отраслей
Мы же говорим об области информационных технологий. Область работает с информационными потоками, их анализом и системами различного порядка. То есть приходится работать с чем-то у чего очень высокая внутренняя сложность. В идеале для этого нужны прикладные математики, но где их взять в нужном количестве?
Следующий момент, IT - это мощный рычаг для бизнеса, который может кратно снижать операционные затраты и кратно увеличивать выручку. Поэтому в IT идет большой поток денег и инвестиций. Да, рычаг капризный, вместо кратного снижения затрат может их кратно повысить, но некоторым везет.
В результате имеем быстрое развитие на фоне недостаточных темпов подготовки профессиональных кадров (желательно на уровне выпускника аспирантуры и выше) при наличии огромного числа случайных людей, привлеченных шальными деньгами.
Плюс повальная «безграмотность» заказчиков, которые не обязаны являться IT-специалистами. Когда это соединяется с большим процентом случайных людей в отрасли, происходит каскад интересных реакций и появление определенных катализаторов.
То есть для меня, как человека с профильным образованием, который в отрасли уже давно, все выглядит понятным и предсказуемым. Плюс я уже знаю в какие места лучше просто не заходить. А для человека со стороны это выглядит, как какая-то непонятная вакханалия.
Комбинация обычных факторов, которая редко встречается в остальных областях. Плюс перегретый рынок.
Реально, звучит практически как начало пути электротехники. Будем надеяться, что со временем остановится эта гонка за инновациями ради самой гонки и придет таки стандартизация, за ней образование и квалифицированные кадры
Беда в том, что это не звучит, как "начало пути электротехники". Эта гонка родом прямо оттуда, это она и есть. Просто теперь передний фронт назвали IT. )))
Отрасль сложная, требует высокой квалификации и профессионализма. Таких людей немного, а работы много, поэтому начинаются компромиссы. Это в строительстве можно использовать неквалифицированный труд, а в IT так не получится.
В целом, отрасли колеблется между несколькими полюсами. Один из полюсов это сверхпрофессионалы, которые используют RAD-технологии. Проводя аналогию со строительством, это человек, который в одного строит многоэтажку за сроки вдвое ниже обычных, но не с не меньшим качеством. Как результат, образуется очень узкий рынок специалистов, которых невозможно заменить. Бизнес вынужден избегая рисков уходит на другие технологии.
Второй полюс мы сейчас с вами будем наблюдать сейчас. Это попытка использовать орду «типа программистов», под руководством нескольких профессионалов. Но так можно делать только небольшие и несложные задачи типа шаблонных сайтов и интернет-магазинов.
На третьем полюсе ведутся работы по автоматизации. То есть нам на самом делен не нужны выпускники онлайн-школ, которые будут делать сайты. Можно сделать конструкторы сайтов типа Тильды и дать потребителям самим все сделать. Аналогично с сервисами, которые автоматизируют и интернет-магазин, и склад и всю бухгалтерию для МСБ, замкнув все в единую экосистему.
В 2000-м году был прорыв команд высокомотивированных профессионала, которые задекларировали Agile. Всё классно, но с падением уровня общей компетентности на рынке, все перестало работать.
Можно сказать, что отрасль идет по восходящей спирали. Оно только выглядит, как нечто хаотичное за счет очень высокого темпа движения и наличии в отрасли большого количества молодых и случайных людей.
нет, потому что одно и тоже прописанное на бумаге можно реализовать не одним способом
И нужно выбирать способ целесообразный. Лампочку тоже можно запитать золотым шинопроводом, но мы закидываем всегда стандартизированный кабель.
Вот у нас на обслуживании была и есть "лампочка", но с началом Covid-19 выяснилось, что тот запас по мощности, которые закладывался, оказался недостаточным (нагрузка просто в разы превысила теоретический максимум). И золотая шина тоже бы сгорела. Пришлось изобретать звездолет и собирать его из подручных материалов прямо на ходу.
Самое смешное, что это "обычное дело" для IT. Есть и обратные примеры, когда закладывают мегаинфраструктуру для какой-то мелкой задачи.
Ну вот представьте ситуацию, вы закладываете стандартизированный кабель, а в ТЗ можете написать только кабель. Заказчик приходит и говорит, почему кабель медный, а не золотой? Хочу золотой, думал будет золотой, у соседа золотой. Ваши действия?
Элементарно. "В соответствии с ГОСТ Р *номер-год* пункт такой-то выбран кабель". А, ну да, стандартов нет и не предвидится
В программировании в плане стандартов есть только либо стандарты процесса (разработки, контроля качества), либо стандарты протоколов обмена данными, либо стандарты информационной безопасности, либо стандарты эргономики. Аналога каких-либо гостовских таблиц вида "для помещения объёмом X м3 выбираем предусмотрен кондиционер мощностью Y кВт" нет.
Как правило, нагнуть получится, если разработчик не уложился в график работ или сделал совсем нерабочее решение. С другой стороны, это гарантированно приведёт к отказу от дальнейшего сотрудничества, а доделывать проект у нового подрядчика может оказаться дольше и дороже, чем у старого.
Разница со строительством, на самом деле, существенная:
- в строительстве сначала идёт этап проектирования на бумаге с учётом хотелок заказчика, затем по этому проекту построить/достроить здание может относительно любой подрядчик.
- В современном программировании отдельного этапа полноценного проектирования архитектуры, бизнес-анализа и дизайна не предусматривается, только грубо прикидывается общая схема продукта. На самом деле хотелки по продукту появляются спонтанно и могут противоречить ранее выполненным задачам.
- Несмотря на типовые решения, многие детали реализации пишутся с нуля под конкретные требования проекта, даже если компания уже раньше реализовывала подобное на других своих проектах (требования копирайта), либо исходя из предпочтений разработчиков. В аналогии со строительством, на пятом этаже здания пришлось придумывать хитрое перекрытие, потому что заказчик захотел огромное помещение без несущих конструкций; батареи отопления имеют левую резьбу, потому что компания-подрядчик — официальный партнёр поставщика таких батарей.
- Строгих требований по качеству, регламентам работы, архитектурным требованиям в обычном "гражданском" программировании нет. Как правило, очень многое зависит от опыта непосредственных разработчиков (которые могут внезапно уйти на другой проект или уволиться).
- Знания о проекте (архитектура, особенности реализации, требования к бизнес-логике и дизайну) хранятся в головах разработчиков даже если какая-то часть вынесена в документацию. Почти никогда никто не может гарантировать, что документация полна, точна и актуальна: учитывает все особенности, детали и нюансы, не содержит устаревших требований.
Уф, все это звучит так, будто айти находится на уровне "строим, как в аулах". Ужасно
Ну опять мимо. IT активно развивается ближайшие 15 лет, а строительный опыт много тысяч лет. Просто мы делаем то чего не знаем сами и не знает тот кому мы это делаем. Когда это понимают обе стороны то ворятность достижения результата наиболее высока. Скорее это все как сторить завод по описанию на словах и глядя на соседний
Какие 15? Лет 40 как минимум. За это время можно было прийти к какой-то стандартизации и нормам
Так есть стандарты и нормы. Есть ГОСТ, кроме шуток, есть ISO, есть ITIL.
Но оно настолько сложное и «живое» в применении, что запускается не у каждого в руках. Иногда просто нужна магия системного мышления, иначе никак.
Беда в том, что начиная с некоторого уровня IT - это искусство, а не ремесло. Воспроизводимость не та, чтобы задать твердые стандарты.
Все равно, это все смотрится, как то же электричество конца 19-начала 20 века. Ноль стандартов, кто во что горазд.
В айти, кстати, нет аналога проектных отделов? Именно тех, кто ответственен за "искусство"
Конечно есть. Работают бизнес-аналитики, системные-аналитики, целая иерархия архитекторов и руководители проектов. Но мало иметь название должности, нужно еще ей соответствовать. А на рынке кризис компетенций.
Например, когда мы начинаем сложные проекты, мы первым этапом продаем этап проектирования, на котором выясняется, что хочет заказчик, сколько на это готов потратить, как этого можно достигнуть в бюджет. Но так делают далеко не все.
Про 40 лет вы немного ошиблись, больше. Если взять «Мифический человекомесяц» Брукса, который представляет собой набор журнальных статей 70-х годов, то можно увидеть набор похожих проблем. Потребности отрасли растут быстрее, чем можно готовить профессионалов для области.
Короче говоря, у отрасли виден кризис из-за недостатка квалифицированных кадров, которых невозможно получить до тех пор, пока отрасль не станет стандартизированна.
Немного не так. Отрасль всегда была в перманентном кадровом кризисе (с момента рождения) и имеет темпы роста, при которых стандарты очень быстро отмирают. Стандартные методы не помогают, вот людей и заносит куда-то не туда постоянно.
То есть они реально отмирают, а не совершенствуются? Почему?
Возникают новые технологии с новыми возможностями и все уходят туда.
Звучит очень неразумно
Представьте, что еще недавно производительность аппаратной базы удваивалась раз в несколько лет. Задержка в полгода стоила многим компаниям жизни. Например, тот же MS Excel в свое время вышел из аутсайдеров и потеснил на глобального лидера Lotus 123 за счет того, что просто написали софт под новый процессор на пару месяцев быстрее.
Либо в какой-то момент начинается эра виртуализации. Возможность горизонтального масштабирования - это не шутка для бизнеса.
Либо то, что раньше могло быть лишь десктопным, стало возможно делать на web-интерфейсах, что существенно сокращает затраты на инфраструктуру.
Можно работать и по старым стандартам, но лет через 5-10 можно просто прекратить свое существование. То есть это не просто погоня за модой.
Ясненько. Ну и теперь понятно, почему тот же эксель не приобрел новых функций за 20 лет, а только оброс требованиями к железу. Благодарю за дискуссию! Теперь я еще больше рад, что смылся из iot)
Да при чем тут стандартизация. Для того чтобы была стандратизация нужно чтобы рынок перестал развиваться и умер или встал на долгую паузу. Тогда будет время что-то стандартизировать. А когда каждый месяц меняются языки, подходы и требования не может быть стандарта.
Вы не понимаете ничего толком, но пытаетесь умничать. IT развивается огромными шагами. Вчера ты делал и год учил одно чтобы быть лучшим, а сегодня выясняется что появилось что-то другое, а то что знаешь ты уже становится не нужным. Это не беда разработчиков только, вся отрасль не успевает, те же вузы готовят абсолютно по другому относительно того что в реальности
Да вот что-то развития со стороны не очень то и видно. Как все ПО тормозило, пыхтело и вылетало, так и продолжает делать спустя 15 лет.
берите то что было 15 лет назад, оно отлажено и работает ок. По моему на самолетах мелких цесна или типа того софт лет 30 не меняют особо. А так железки очень быстро лепят, кадры готовятся дольше, поэтому странно видеть тезисы что ойтишнки никому не нужны будут через 5-10 N лет. Тут направлений за 5 лет столько всего наклепали работы на всю жизнь хватит
Откуда 40-то) С луны свалились что-ли. В среднем у большинства ПК появились в 2005, а интренет и того позже
А, ну да, "ваши микрософты с мсдосами не айти". Домашние пк так вообще без разницы когда появились у масс, потребители айти продукта были и до них
Ну на перфокартах печатали когда это IT уже или нет по вашему?
Даже лампы-уже айти
Так и есть по факту. И даже у гигантов ит-рынка. Более-менее регаментирована и зарегулирована только разработка для критической инфраструктуры типа авиации, энергетики, военки и т.п.
На самом деле тому виной ещё и гораздо более сильные различия в требованиях между проектами (намного сильнее, чем между жилым домом, офисным зданием и торговым центром), дороговизна разработки и желание сэкономить на сроках и цене.
Ну, существенная часть отрасли так и работает. Где-то треть, наверное.
Договор есть. Но мало кто идет в суды, так как тогда уж точно надо будет начинать проект с нуля, то есть потеря времени, денег, поиск нового подрядчика и потеря времени, сил, нервов, денег на судебное разбирательство с неопределенным судебным решением. Большая компания со штатом юристов на это пойдет. Небольшая скорее всего - нет.