Риски сотрудничества с разработчиком, которые никто не оценивает на старте

Проблема 1. Слабая погруженность в проект

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

Большинство заказчиков уверены, что не вовлеченный в проект подрядчик — это высокий риск провала. Команда, не погруженная в отраслевую специфику или в цели проекта, вряд ли сможет делиться своей экспертизой, предлагать улучшения, оптимизировать процессы. Такие команды быстро выгорают и в итоге просто формально следуют требованиям ТЗ.

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

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

• Опыт исполнителя и наличие реализованных заказных или собственных проектов в нужном сегменте.
• Готовность подрядчика делиться информацией или идеями еще на этапе знакомства или пресейла.
• Оценка подрядчиков требований к проекту — готов ли он их обсуждать и предлагать более эффективные решения сразу или молча принимает требования для формального следования ТЗ.
• Открытость, способность рассказывать о провалах, проблемах на проектах, о том, как решались сложные ситуации.
• Быстрота реакции, качество коммуникации на самых первых этапах взаимодействия.
• Готовность на этапе пресейла представить заказчику не только менеджера по продажам, но и познакомить с техническими специалистами, руководителем команды.

Если у подрядчика есть реализованные проекты или собственные продукты в нужном сегменте рынка, это подтвердит как минимум знание предметной области. А значит, команда будет быстрее погружаться в бизнес-задачи, сможет использовать собственный опыт для более эффективного решения задач.

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

В идеале в команде разработки должен быть своего рода «технарь-развиватор», человек, который обладает не только глубокими техническими навыками, но и хорошо знает рынок клиента и потребности конечных пользователей создаваемого продукта.

Заказчики ценят инициативность, помощь в решении проблем, более широкий взгляд на задачи, а не формальное их закрытие в соответствии с ТЗ. Многие компании организуют более глубокое погружение команды подрядчика в детали своего бизнеса, рассказывают, что именно они предлагают своим клиентам, какие ценности несут пользователям. 

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

Читайте по теме: Заказная разработка или коробочное решение: о чем важно помнить при выборе

Проблема 2. Отсутствие доверия на проекте

Подрядчик работает в автономном режиме, не раскрывает промежуточные результаты работы.

Заказчики ожидают, что исполнитель погрузится в бизнес-задачи проекта и сможет предлагать более эффективные решения, учитывая при этом три классических условия — бюджет, качество и сроки. Именно подрядчик должен понимать, что из условий можно менять, чтобы не проиграть в качестве — пожертвовать сроками или объемом работ, насколько велики ограничения по бюджету и другое.

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

Алексей Юрлов, директор по информационной безопасности в благотворительном фонде «Вклад в будущее» от «Сбера», привел отличный пример на этот случай. Представим, что мы производим молотки. Они должны хорошо забивать гвозди. А если заказчик хочет, чтобы в них еще и wi-fi работал, это точно станет проблемой для всех участников проекта.

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

Многие заказчики отмечают отсутствие четкой коммуникации на проектах. Одинаково плохо, когда общение между командами заказчика и подрядчика минимально, и когда его слишком много и все общаются со всеми. Четких правил здесь нет, коммуникацию нужно выстраивать так, как удобно всем сторонам.

Например, крупные компании и госструктуры предпочитают, чтобы на проекте с обеих сторон были аккаунт-менеджеры, ответственные в том числе и за коммуникацию, синхронизацию информации о проекте.

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

Проблема 3. Заказчик слишком поздно узнает, что в проекте проблемы и он не будет завершен в срок

На проектах случаются форс-мажоры — отзыв лицензии на используемое ПО, внезапная замена специалиста в команде разработки и так далее. Это может повлиять на сроки, и предусмотреть такие ситуации заранее невозможно.

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

Если в конце проекта подрядчик говорит «упс, тут такая штука сложная выяснилась», опыт заказчика подсказывает, что это не могло произойти за последние сутки. Вероятнее всего о проблеме было известно намного раньше, просто о ней молчали.

Неумение эскалировать сложные ситуации, вовремя озвучивать их и сразу брать в работу, характерно для обеих сторон процесса. Заказчики, с которыми мы общались при подготовке статьи, утверждают, что проджект-менеджеры исполнителей всегда боятся говорить о сложностях. Но, как исполнители, мы знаем, что до последнего может молчать и сам заказчик, скрывая проблемы на проекте.

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

Одна из причин затянутых коммуникаций, как ни странно, Agile-методология. Чаще всего непредусмотренные проектом задачи или проблемы озвучиваются в начале недели или спринта, а потому вопрос ждет решения до следующей планерки, где озвучивается в конце обсуждения — только тогда находится причина проблемы, ее начинают исправлять, на это уходит еще неделя или две.

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

Перспективы клиентского сервиса в заказной разработке

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

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

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

Читайте также:

Как задача по набору китайского текста привела к созданию автозаполнения

«Требуются сотрудники для удаленной работы. Высокий доход, гибкий график»: кто такие дропперы и что им грозит

Рекомендации для заказчиков

1. Проверять опыт подрядчика в нужной отрасли — отзывами предыдущих клиентов, наличием собственных продуктов в отрасли
2. Проводить собеседования не только с менеджерами по продажам или руководителем проектов, но и с командой — техлидами, аналитиками и другими.
3. Настаивать на том, чтобы на стороне подрядчика был технический специалист, понимающий бизнес-задачи проекта.
4. Погружать команду подрядчика в бизнес-задачи проекта. На всех уровнях — от руководителя команды до конечных специалистов.
5. Уметь погружаться в проект наравне с подрядчиком, перерабатывать, работать в быстром темпе
6. Закладывать в проект по Fixed Price до 30% по срокам и деньгам, если такое возможно.

Рекомендации для разработчиков

1. Организовать прозрачные коммуникации, использовать понятные инструменты взаимодействия (каналы связи, таск-трекеры, планировщики задач и другие), иметь в штате опытных проджект-менеджеров, оставаться на связи и вовремя предоставлять нужную информацию.
2. Уметь быстро погружаться в бизнес заказчика, не стесняться задавать вопросы, не давать завышенных обещаний. 
3. Проявлять проактивность с самых первых этапов взаимодействия. Управлять процессом разработки.
4. Соблюдать сроки, умение работать в формате, удобном для заказчика: Time&Material для стартапов, Fixed Price для крупных заказчиков или просто работать очень быстро и качественно, если заказчик — госструктура.

Фото: Unsplash