Как бизнесу успешно запустить проект разработки
Разработка цифровых продуктов — это сложный процесс, требующий четкого планирования и слаженной работы не только команды подрядчика, но и заказчика. В этой статье поделюсь ключевыми советами, которые помогут бизнесу успешно запустить проект разработки, соблюсти все дедлайны и не выйти за рамки бюджета.
ТЗ и требования к продукту должны соответствовать реальной задаче
Для того чтобы команда разработчиков смогла представить наилучшее решение, необходима исчерпывающая информация о готовящемся ИТ-продукте. При этом есть один нюанс: сами клиенты зачастую не могут четко определить и предсказать, с какими системами предстоит осуществлять интеграцию.
Если на этапе старта разработки не определить порядок взаимодействия с партнерскими интеграциями или основные технические устройства, для которых будет создаваться программный продукт, а также, например, список оборудования и основные сценарии интеграции, вероятнее всего возникнут проблемы. Так, например, может выясниться, что партнеры не имеют API для интеграции, а устройства имеют определенные технические ограничения, которые не были учтены заранее. Это значит, что потребуется дополнительное время на изучение возможных рисков и поиск альтернативных вариантов решения.
Прежде чем стартовать разработку, необходимо обсудить с командой ключевые аспекты бизнеса и особенные запросы и предпочтения — возможно, есть необходимость в создании решения на определенном стеке. Появление новых требований уже в процессе выполнения проекта может существенно увеличить его стоимость и сроки. Чтобы избежать таких ситуаций, компании-заказчику следует открыто и максимально полно отвечать на уточняющие вопросы, которые задает команда подрядчика.
Еще один совет для синхронизации ТЗ с реальностью: постарайтесь пообщаться с конечными пользователями продукта или системы еще до подписания договоров, так вскроются дополнительные детали, которые не были видны в самом начале.
Без четкого целеполагания — никуда
Ясное понимание целей проекта и их четкая передача подрядчику помогут команде составить более точную смету и план выполнения. Например, не всегда необходимо начинать ИТ-разработку с нуля.
Иногда целесообразнее начать с модификации уже существующего программного решения, а затем переходить к разработке индивидуальной ИТ-системы. В некоторых ситуациях можно, например, сразу приступить к созданию минимально жизнеспособного продукта (MVP), что позволит получить результаты в кратчайшие сроки.
Постарайтесь устранить разрыв в коммуникациях
Работая с одним из проектов, мы улучшали процесс инвентаризации оборудования и каналов связи. Учет оборудования разных технологий велся в разных системах, даже файлы Excel использовали. Работать с данными для планирования сетей было сложно — необходимо перенести все в единую систему, а затем запустить планирование сетей с учетом всех этих данных.
Data Migration Lead подключился на ранних стадиях проекта для анализа данных. 83% всей информации из первого региона прошло валидацию и легло в новую структуру, но, в следующем мы получили поврежденные данные. В результате оказалось, что существует еще две системы учета оборудования. Заказчик работал в центральном регионе и о них не знал. Мы оперативно выпустили дополнительное ТЗ, подписали дополнительное соглашение, но бюджет пришлось увеличивать.
Заказчик не обязан быть экспертом в IT-сфере и знать все тонкости процесса разработки. Но тем не менее, непонимание основных этапов, отсутствие четкой коммуникации и обратной связи может привести к серьезным проблемам.
Не задерживайтесь с выдачей доступов и обратной связью
Бывают случаи, когда клиенту нужно получить промежуточный результат через определенное количество месяцев. Но выдача доступов для работы команды исполнителя через внутреннюю службу безопасности происходит очень медленно и иногда «съедает» несколько месяцев. К такому результату приводят задержки не только из-за отсутствия необходимых доступов и материалов, но и из-за согласования работ.
Подрядчику может понадобиться доступ к клиентскому таск-трекеру, его сервисам и ИТ-инфраструктуре, а также к API для интеграции. Кроме того, ему потребуются контент или устройства, для которых планируется разработка, например, мобильные приложения или оборудование.
Для всех будет лучше, если все материалы и ресурсы, необходимые для работы подрядчика, будут готовы своевременно
Если подрядчик не получает обратную связь от клиента в установленный срок, то он вправе выставить счет для оплаты за простой, а в качестве крайней меры даже распустить команду, пока клиент не будет готов продолжить сотрудничество по проекту.
Такие действия несут определенные риски, так как на подбор новых экспертов и их погружение в проект потребуется дополнительное время. В итоге это отразится на сроках и стоимости разработки. Так что для всех будет лучше, если все материалы и ресурсы, необходимые для работы подрядчика, будут готовы своевременно.
Микроуправление и избыточный контроль вредят проекту
Некоторые клиенты предпочитают тактику микроуправления, обеспечивая постоянный надзор за процессом выполнения каждой задачи.
Чтобы вовлечь клиента, подрядчику нужно регулярно встречаться с ним, рассказывать о прогрессе. Это могут быть как совместные обсуждения с командой, так и встречи руководителя команды исполнителя с представителем заказчика тет-а-тет. Также клиент с определенной периодичностью получает отчет, сколько времени потрачено на разработку, чтобы контролировать бюджет.
Но бывает так, что клиент несколько раз в день инициирует обсуждения по проекту с присутствием всей команды. При этом предмет рассмотрения не всегда связан с текущей задачей или форс-мажором. Такие встречи отнимают у команды разработки время, которое можно было бы потратить на работу.
Поэтому важно осознавать, что главным связующим звеном между вами и командой разработчиков является проектный менеджер. Прямое обращение к разработчикам с заданиями или через чаты совсем не продуктивный подход. В ИТ-командах принято, что все задачи и требования поступают к исполнителям через руководителя проекта. В некоторых случаях чрезмерный интерес клиента к методам реализации конкретных задач может даже демотивировать команду.
Правильно выбирайте кураторов проекта
Иногда компания-заказчик назначает сразу несколько ответственных сотрудников на проект или привлекает к экспертизе непрофильных специалистов.
Обычно эта ошибка связана с отсутствием критериев оценки результата: текстов, дизайна, качественных характеристик ПО или системы.
Так, например, дизайн принимает главный бухгалтер клиента по принципу «нравится-не нравится». В результате сроки запуска проекта увеличиваются на несколько месяцев.
Всегда тестируйте продукт
Некоторые заказчики предполагают, что смогут сэкономить свое время, отказавшись тестировать продукт перед релизом, и якобы всецело полагаются на разработчика. К сожалению, при таком подходе, к пользователям так или иначе попадают баги, а после релиза заказчик переживает их правки более болезненно, чем в случае, когда они были обнаружены на этапе тестирования. Обычно в таких ситуациях страдает лояльность реальных клиентов и также растягиваются сроки сдачи работ.
Как избежать ошибок
Чтобы создать хороший продукт, нужно не просто составить список его желаемых функций, но и обеспечить прозрачную коммуникацию и доступ к ресурсам для всех участников проекта. Вот еще несколько важных моментов, которые необходимо учесть перед запуском разработки, чтобы минимизировать ошибки:
- точно определить требования к системе, расставить приоритеты и своевременно сообщать об их изменении;
- ознакомить аналитиков и разработчиков с особенностями бизнеса;
- изучить разработанные спецификации требований и оценить прототипы;
- сформулировать четкие критерии результата проекта и его отдельных этапов, всегда стремиться к единому пониманию оценки и ее наполнения;
- назначить ответственное лицо, которое будет принимать решения от имени заказчик и взаимодействовать с разработчиками;
- всегда помнить, что поиск и устранение ошибок — неотъемлемый, непрерывный и очень важный процесс в любом проекте на всех стадиях жизни, а найденная ошибка — всегда праздник, уже хотя бы по тому, что её можно исправить и сделать цифровой продукт чуточку лучше.
Следуя всем указанным рекомендациям вы обезопасите себя не только от финансовых потерь, но и сможете обеспечить своевременный запуск своему проекту и достичь желаемых бизнес-целей.
Не стесняйтесь общаться с разработчиками. Процесс создания действительно классного IT-продукта подразумевает вовлеченное участие обеих сторон. Максимально подробно делитесь своими намерениями, видением и целями, задавайте вопросы о том, что вам неясно, и будьте открыты — тогда результаты совместной работы не заставят себя ждать и точно порадуют.
Мы придерживаемся именно такого подхода, и он работает. Как было сказано в начале, бизнес и разработка объединяются ради общей цели — создания качественного, удобного и востребованного продукта для конечных пользователей.
А у вас был опыт запуска IT-продукта?