Ускорить проект невозможно. Никак, — так и я думал раньше. Но давайте разберемся, как дело обстоит на самом деле. Расскажу, что делать, чтобы вместо планируемых на разработку шести месяцев не получить полтора-два года.

Кто чаще всего главный тормоз проекта? 

Парадоксально, но сам заказчик. Это сложно принять, но давайте сначала докажем, а затем расскажем, как и что с этим делать. 

Когда мы в компании^{_{[отредактировано модератором]}} делали свои продукты, то он завершались в пару раз быстрее, чем проекты для сторонних заказчиков. Почему?

Из общей схемы уходила коммуникация — ожидания, что скажет заказчик, бумажки, согласования. Решения принимали люди на местах, брали на себя ответственность, и проект летел: не месяцы и годы разработки, а недели. Как вам такое?

Он платит, и он еще и виноват? Именно

Разумеется, ты не можешь разрабатывать проект для клиента, не спрашивая его, все ли ок. Ты же все время с ним общаешься: «Слушай, дорогой клиент, мы тебе нарисовали эскизы. Хорошие эскизы?» Он отвечает: «Хорошие!» или «Нехорошие!». «Почему нехорошие?» — «Да потому!». И понеслось. 

Это касается любых вопросов, не только «выбери эскиз». Например, решаем: «Здесь вот на корпусе у нас будет кнопочка. Да?» Вот это «Да?» потом выливается в несколько суток ожидания. Наш сотрудник ждать столько не может и переключается на другой проект. Потом клиент возвращается с ответом: «Да!». А поезд уже убежал, ведь сотрудник думает уже о другом проекте, и ему нужно потратить время на повторное погружение в задачу.

Хозяйке на заметку: закладывай время на переключение с одной задачи на другую для разработчика. Сколько именно? Не меньше, чем нужно на выполнение этой самой задачи.

Как только мы заставляем клиента что-то выбирать, что-то выяснять, искать информацию — в этот момент начинаются тормоза. Они со стороны клиента кажутся слабенькими: «Ну а чё, денёчек-два мы там это обсудим», а на деле все выливается в недели тормозов потом. 

Это нечто вроде накапливающегося технического долга, но связанного не с ошибками в программном коде, а с пренебрежением ко времени. Я об этом говорил в одном своем выступлении: после того, как мы проанализировали свои разработки за 2017—2019 годы, то увидели, что все проекты, которые мы делали, длятся вдвое дольше, чем это было запланировано изначально. Вот все. 

Отдавай и властвуй. Способ ускорения номер раз

Всё это кажется нелогичным и вообще абсурдным — да, ты же не можешь сделать проект заказчику без участия его самого. Но и интенсивно коммуницировать во время хода разработки нельзя. Как можно? 

Взять все, да и поделить ©. Подрядчик (допустим, мы) делит с заказчиком ответственность за принятие решений. Всего у нас в ТЗ на работу есть, например, 100 условий; из них 10 — важные, 80 — неважные, 10 вообще ни на что не влияют. Надо выбрать из них критические, то есть те, которые повлияют на ход проекта фундаментально. И отдавать на сторону заказчика только их. 

Остальные — оставлять подрядчику (себе): клиент будет делиться с нами ответственностью, то есть разрешать нам принимать решения.

Выбрать самые важные условия очень просто. Это те, несоблюдение которых убьет проект. Смотрим на примерах.  

• Если у тебя цвет корпуса не влияет на завершение проекта, убирай это условие: решение, какой расцветки будет корпус, остается за подрядчиком. 

• Если какая-то определенная степень герметичности корпуса не нужна, тогда этот вопрос решает подрядчик. 

• Выбор размера дисплея — это не критическое условие, а наличие разъемов — критическая: без разъемов у тебя проект не стартанёт, а с дисплеем — любым, маленьким или чуть побольше, — вполне. Решение по разъёмам принимает заказчик, по дисплею — подрядчик.

Приём 1: сядьте с подрядчиком над итоговым ТЗ и пройдитесь по каждому пункту — насколько это важно для выхода проекта в производство и продаж? Если что-то не так уж важно, отдайте решение подрядчику.

Режем сроки. Способ ускорения номер два

Конкретная ситуация — мы разрабатывали манипулу для корпуса лазерного эпилятора. Внезапно клиент захотел напечатать макет на 3D-принтере.

Что проверяется 3D-печатью? Удобство использования в том числе — насколько эта штука эргономична. 

А может ли подрядчик без клиента решить, удобно или нет? Представьте себе, да. Заказчик мог предоставить удобный референс (манипулу конкурента), и тогда дизайнеры по аналогии сделали бы похожее. Это сэкономило бы несколько недель: здесь мы вообще отправляли макет в другую страну для «подержать в руках».  

Так заказчик нечаянно замедлил проект на несколько недель: пока напечатали, пока отправили, пока выставили счет, пока все прикрыли актом, пока получили ответ. Сама работа по изменению заняла несколько дней, но все, что её окружает, отожрало пару месяцев времени.

Хозяйке на заметку: рассчитывайте время на выполнение конкретных работ с учетом реалий. Если только пересылка макета (даже не прототипа!) туда-сюда съест месяц или два, может, так уж это и нужно. 

Ещё пример. Сроки разработки штанги для дозиметра были определены на старте работ примерно в 9 месяцев. В реале проект растянулся на два с лишним года и ушел в закат на этапе прототипирования первого образца. Только с макетом штанги пришлось ковыряться пару-тройку месяцев, а потом выезжать к клиенту, едва ли не хватать его за грудки и требовать определиться с эргономикой. Иначе не получалось. 

Почему? А потому, что клиенты разные, и у этого не было ответственного за проект. Зато имелись финдиректор, менеджер проекта и конструктор, которые занимались не только «нашей» штангой, но и другими разработками плюс периодически уходили в отпуск/на больничный, а в перерывах тянули одеяло каждый на себя. Собственно решения (один раз в неделю) принимали не они, а вообще технический директор.  

Прием 2. Договаривайтесь, чтобы заказчик назначил вам для коммуникаций кого-то одного, действительно ответственного за проект, а не цыганский табор группу лиц. 

Прогнать через призму. Способ ускорения номер три

Но как побудить заказчика прописать все условия в ТЗ? Он же все равно что-то забудет, упустит. Как вытащить действительно важное?

Это нужно делать еще до запуска, в разговоре «на берегу» — собирать все смыслы и требования, прогонять их через призму приоритетов заказчика и подвергать сомнению любое требование ТЗ. 

Заказчик: «Нам очень важно, чтобы устройство было вот такого размера, не больше». 

Подрядчик: «Это действительно так важно? Почему?»

Вот есть здоровый чемодан, полный нейродатчиков. Заказчик хочет чемодан-слайдер, чтобы в него можно было запихнуть ещё больше этих датчиков. Я спрашиваю, зачем ему это надо — чтобы можно было больше перевозить? А может, тут достаточно пакета или мешка? 

И — раз! — выясняется, что чемодан вообще не нужен. Потенциальному заказчику он просто не нравится — большой, неудобный; клиенту приходится постоянно таскать с собой три чемодана, все здоровые, и ему это сильно не по душе. 

Ок, мы впихнем слайдер, уменьшим этот чемодан на 30% и будем долбаться с этим слайдером год. «Вас это устроит?» «Нет, я и не подозревал, что это такой геморрой». 

Ещё вопрос: является ли для проекта уменьшение размеров чемодана критичным условием? Да вообще нет. Расходимся. 

Или совсем шикарный свежий случай: заказчик пришел к нам с корпусом, который попросил переделать. Естественно, мы поинтересовались: «А в чем проблема с этим?» «А он не радиопрозрачный», — пожаловался заказчик. 

Смотрим еще раз на корпус — а он из металла. Занавес.

Итого: есть обязательные требования, есть рекомендуемые. Надо очень четко их для себя разделять. Обязательные — с этим все ясно; за их несоблюдение ты получаешь полное право иметь подрядчика как хочешь. Рекомендуемые — ты в это не лезешь вообще. И тогда проект пролетит за 5 месяцев вместо, допустим, двух лет. 

Прием 3. Сразу вытащи важное из заказчика — если ты подрядчик. А если ты — заказчик, спроси подрядчика, без чего в этом проекте вполне можно обойтись.

Ещё ТОП-3 тормозов проекта, которые едят время

1. Ожидание электроники. 4 из 5 проектов эту боль точно испытывают. 

К моменту разработки корпуса у тебя толком не подобраны компоненты, хотя так-то есть стендовый макет, принципиальная схема: все это на столе лежит и вполне себе работает. Но нет спецификаций на каждый элемент, нет BOM-файла. 

И тут ты решаешь «немножко заменить» железку — например, решили взять другой дисплей, поставив компонент с чуть большей зоной видимости. Казалось бы, задача вообще фигня, всего-то рамку перерисовать. 

Но. 

Любой дисплей, как и любой электронный компонент, нужно куда-то подключать. Для этого есть шлейф. Шлейф может влиять еще на какую-то деталь. И теперь у нас есть изменение нескольких сопряженных друг с другом деталей вместо одной. Работу ты не можешь начать, пока тебе не дадут спецификацию дисплея (либо не привезут живой компонент — образец). Ты как заказчик тратишь время на выбор — вы обсуждаете дисплей в своем кругу: где его взять, как взять подешевле; вы его наконец покупаете, он едет из Китая, вы его тестируете; наконец, дисплей передают конструкторам. 

Это все — недели временных затрат только потому, что вы решили «немножко изменить» размер дисплея.  

На самом деле это и не плохо, и не хорошо, а нормально: ты же не просто так меняешь характеристику, а качественно улучшаешь продукт.

Но является ли это критичным для прибора в целом?

2. Утверждение компоновки. Важная штука, но, на мой взгляд, она не является критичной, ее вполне можно отдать разработчику. 

3. Утверждение 3D-модели и печать макета. Зачем это нужно — чтобы заказчик посмотрел и кивнул? На самом деле вот зачем — чтобы он засомневался: «Ой, что-то кнопочки маловаты, нельзя ли сделать побольше?» 

Ну и всё. Тормознули, огребли, переделываем кнопочки. Дальше действует уже знакомое правило: чем дальше разработка, тем больше прибавляется к общему сроку. 

Сколько именно? Навскидку: один день избыточных согласований в начале проекта — плюс неделя к общему сроку. Один день в середине — две. Один день ближе к финалу — месяц. Так полгода и превращаются в два. 

Вывод

Как убрать тормоза, если продукт надо кровь из носа сдать в производство к намеченному сроку — назначить одного ответственного за проект и свести коммуникацию с заказчиком непосредственно в процессе разработки к минимуму, заранее определив критические условия проекта и запретив заказчику вмешиваться в работу подрядчика. Примеры критических/некритических условий и критерии их определения мы уже привели. 

Или ещё один вариант: контролировать все. Но тогда настройтесь на два года. Зато получится именно так, как вы себе это представляли в мечтах.

А вы готовы доверить 80% решений разработчику?