Если бы мы жили в мире розовых пони, то каждый проект выполнялся бы в строгом соответствии с планом. В реальности же проект может застопориться практически в любой момент. Впрочем, можно выделить три этапа, на которых такое случается чаще всего.
1. Этап согласования требований к проекту
Нередко причина в том, что заказчик не понимает или не может ясно выразить, чего он хочет. Да-да, это тот самый случай с «нехорошим» ТЗ и такими же результатами.
Команде непонятны функции разрабатываемого решения, что в нем играет ключевую роль, а что вторичную, где и как оно будет использовано и т.д. Отсюда и непонимание того, какими техническими характеристиками должно обладать устройство.
Бывает и так: заказчик четко знает, чего хочет, но хочет слишком многого – и подешевле, пожалуйста! Обычно такие клиенты не имеют опыта в данной сфере и потому не осознают, насколько сложным, масштабным, длительным и, как следствие, дорогим может быть проект.
И здесь приходится вести длительные переговоры, согласовывать общую концепцию продукта, переписывать ТЗ или просто доказывать заказчику, что с его ресурсами сделать задуманное не получится.
Часто согласовать требования не получается потому, что в процессе не участвует лицо, принимающее решения (ЛПР). Обычно это собственник бизнеса, который заинтересован в разработке, платит за все это удовольствие и принимает конечный продукт.
Бывает, что начальство поручает согласовывать проект кому-то из подчиненных, а он человек подневольный и сам ничего не решает. Согласовав что-то с командой, он бежит согласовывать этот же вопрос к начальству. И тут может случиться самое разное. Начальство может неправильно понять подчиненного (эффект глухого телефона), не воспринять его всерьез, не поверить аргументам и т.д.
Так что лицо, принимающее решения, обязательно должно участвовать в согласовании требований, иначе этот процесс слишком затянется.
2. Испытание первого прототипа
Собрать полностью рабочий прототип устройства с первого раза едва ли возможно. Мы уже много лет занимаемся разработкой, и потому всегда предупреждаем заказчика, что прототипов придется делать как минимум два, потому что у первого обязательно будут какие-то проблемы. Мы всегда закладываем время на устранение недочетов и создание второго прототипа. Но иногда такие недочеты оказываются несколько серьезнее, чем ожидалось.
Приходится тратить больше времени на поиск причин проблемы и ее устранение. Например, может оказаться, что заказанные компоненты не соответствуют заявленным в паспорте характеристикам. Причем это не брак, а скорее бардак у производителя. Значит, нужно возвращаться к предыдущему этапу, выбирать другую модель, возможно, подгонять под нее остальные параметры устройства и т.д.
Тем не менее, такие проблемы не оказываются полной неожиданностью и не приводят к катастрофическим последствиям с риском закрытия проекта. Скорее они могут просто спутать планы, потребовать больше усилий и отсрочить завершение проекта.
3. Этап сертификации
В зависимости от назначения и сферы применения, устройство должно пройти ряд обязательных сертификаций. Так регуляторы могут удостовериться, что прибор не шумит больше положенного, или не токсичен, или не долбанет пользователя током, или не взорвется. Есть и добровольные сертификации, которыми можно пощеголять перед потребителями.
На этом этапе проект может застопориться вновь.
Зная об этом, мы еще на этапе сбора требований выясняем у заказчика, какие сертификации нам предстоит пройти и какие там требования к устройству. В дальнейшем проект разрабатывается с учетом этой информации.
Некоторые стандарты не требуют больших усилий для прохождения. Но есть и такие, пройти которые не так-то просто. И даже если все сделано правильно и устройство отвечает требованиям регулятора, сам процесс сертификации требует много времени. Например, сертификация медицинского оборудования занимает годы!
Если же команда чего-то не учла и устройство не дотягивает до стандартов регулятора, прибор возвращают на переделку. И это может повторяться несколько раз.
При этом сам процесс сертификации (поиск нужных стандартов, оформление документов, регистрацию и пр.) лучше поручить профильной организации.
Проект может застопориться в любой момент из-за чрезмерной увлеченности
Некоторые заказчики постоянно фонтанируют идеями и не могут остановиться на чем-то одном. Требования согласованы, команда подобрана, план работы расписан, бюджет и сроки определены, но тут появляется клиент и говорит: “Ребята, я тут прочитал, сейчас модно компьютерное зрение. Давайте такую же фичу забабахаем!”
Нередко такие идеи требуют значительного переосмысления проекта и перераспределения задач. Это само по себе тормозит проект, оттягивая его завершение. А еще может получиться так, что фичу мы забабахали, но на нее ушли все деньги, и проект встал.
Можно ли точно рассчитать продолжительность проекта?
Некоторые проекты достаточно просты. Мы знаем, как сделать прибор, какую технологию лучше использовать и каким требованиям он должен соответствовать. Тогда команда может довольно точно сказать, сколько времени потребуется на разработку.
Но сложный и масштабный проект предполагает поиск нестандартных решений, поэтому он может застопориться в любой момент – особенно на этапах, описанных выше. Именно поэтому им подходит гибкая методология разработки AGILE, которая сводит разработку к серии коротких циклов.