Как выбрать подрядчика на разработку IT проекта. Какие вопросы следует задавать

Запуск IT проекта — это как рождение ребенка: поспешите с выбором партнера и в какой-то момент будете воспитывать самостоятельно, а «гнилые» гены неудачного партнера останутся...

Ежедневно в мире рождается множество новых IT проектов. Раньше большинство успешных проектов рождалось «на коленке», но время быстрых результатов проходит. Для простых и стандартных задач, всегда найдется готовый сервис, а вот для более сложных и комплексных — необходим совсем другой подход.

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

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

Притча во языцех отрасли. Нарушают сроки все без исключения — разница лишь в том, как команда разработки с этим работает.

Лучшие нарушают только в рамках отдельных этапов и умеют вовремя увидеть проблему. Самые лучшие не только видят, но и знают что делать.

Наиболее распространённые причины нарушения сроков:

• Попытка понравиться и «посадить на крючок» —
  в стремлении понравится клиенту, подрядчик сразу же называет сроки, которые клиенту будет приятно услышать. В основном этим грешат начинающие компании, либо менеджеры по продажам, которые хотят любой ценой заинтересовать клиента. Когда договор заключен, а предоплата внесена — удержать клиента, даже после срыва сроков, становится делом техники.
• Недооценка технической сложности и/или слабая аналитика — разработка любого продукта это работа целой команды специалистов (я не беру фриланс или привлечение внутренних «тыж программистов»). В сложных проектах за функции анализа, проектирования и разработки отвечают разные специалисты. У каждого свое видение и опыт. То, что для одного понятно и прозрачно, для другого может оказаться чем-то сверхсложным.
• Недостаток опыта совместной реализации проектов командой разработки — проекты в IT требуют разных компетенций и состав специалистов. Разработчики, как экипаж корабля — каждый член которой выполняет свою функцию. Даже когда все участники проекта имеют серьезный уровень и не один десяток проектов за спиной, если они работают вместе впервые им потребуется время на «притирку». Чем профессиональнее специалисты и развитее стандарты разработки в компании, тем меньше этого времени нужно.
• Неправильная этапность проекта и/или масштабный горизонт планирования — чем дальше необходимо прогнозировать работу, тем больше накапливается допущений. При проектах длительностью более 3-6 месяцев, вероятность того, что есть четкое ТЗ, которое статично и однозначно, равно 0.0....1%. Чаще всего есть «хотелка», либо приблизительное ТЗ, которое обязательно будет уточняться по мере разработки. При уточнении объем работ имеет свойство увеличиваться, а не снижается.

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

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

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

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

Еще один частый гость в IT проектах — «думали сделаем за 3 копейки, а оказалось дороже, чем построить Боинг». Стоит сразу принять — если продукт будет успешен и будет развиваться, то бюджет обязательно будет расти. Вопрос только в том, насколько это может стать сюрпризом для вас.

Наиболее распространённые причины нарушения бюджета:

• Исполнитель демпингует, чтобы взять заказ — у некоторых участников рынка следующая бизнес-модель: озвучить за реализацию по заданию клиента стоимость существенно ниже большинства конкурентов и даже дать гарантии выполнения. Суть заключается в том, что разработчик выполняет исключительно то, что было зафиксировано и, насколько возможно, минимальными усилиями. В таком случае, не следует ожидать, что будут выбраны стратегически наиболее эффективные решения. Да и необходимость в квалифицированных специалистах не высока - чем больше доработок потребуется в будущем, тем больше вы заплатите.
• Рентабельность на обслуживании и доработках — еще одна бизнес-модель, суть которой: заложить небольшую маржу в начале работ, а уже потом «доить» клиента на доработках и сопровождении. Вероятность того, что хоть одна серьезная команда возьмется за поддержку чужого кода за «приемлемые деньги» очень низка, поэтому вы вряд ли уйдете от них. Как следствие можно продавать вам услуги по обслуживанию и доработкам с существенной маржинальностью, окупая первоначальные риски и упущенную прибыль.
  В данном случае под нарушением предполагается то, что это может быть не предсказуемо для вас изначально, что увеличит стоимость владения продуктом и может сделать его не столь эффективным, как планировалось.
• Недооценка технической сложности и/или слабая аналитика — и вновь этот пункт. Многие заказчики разработки сильно недооценивают необходимость качественной аналитики. Удивительно, но пренебрежительное отношение к планированию и проработке встречается даже среди IT специалистов с опытом.
  Слабое внимание к аналитике - бич отрасли. Продавать аналитику сложно, а за свой счет и сверхурочно ее не хочет делать никто. В итоге, каждый не до конца проработанный вопрос превращается в дополнительную смету, объем которой зачастую непредсказуем.
• Не соответствие результата потребностям и/или ожиданиям заказчика — еще одна вариация плохо выполненной аналитики. Зачастую в голове (да и на бумаге) ожидаемый результат кажется красивым, лаконичным, функциональным... Но вот по факту - часто бывает иначе. Предполагаемая цель может оказаться ложной. Решаемая проблема следствием, а не причиной. Кажущиеся чёткими и последовательными связи могут иметь разрывы и «темные зоны».
  Это наиболее частая причина, почему растет бюджет. Вряд ли вам нужна просто картинка. Скорее всего вы хотите закрыть какую-то потребность и будете готовы заплатить, чтобы получить именно то, что действительно необходимо, даже если это приведет к увеличению изначально запланированного бюджета.

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

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

• Какая методология расчета стоимости проекта? Какое долевое распределение затрат следует ожидать?
• Как часто изменяются цены на услуги и от чего они зависят?
• Сколько будет стоить поддержка проекта после запуска? (тут следует подумать о том, насколько масштабные доработки вы планируете в случае успеха, чтобы не заставлять подрядчика брать цифры из воздуха)
• В каких бюджетах подрядчик заинтересован при долгосрочном сотрудничестве?
• Насколько финансово устойчива компания и как часто она привлекает новые проекты?
• Кто производит оценку стоимости и как она сопоставляется с реально проделанной работой?
  
• Какие риски закладываются в стоимость и закладываются ли?
• Уровень привлекаемых специалистов и цен исполнителя относительно рынка? Подрядчик делает упор на высококлассных и дорогих специалистов, либо на специалистов среднего уровня с подключением начинающих? Предполагается ли замена специалистов в процессе реализации проекта?
• Какие стандарты документирования приняты в компании и возможно ли будет подключение сторонней команды/ухода от подрядчика? Сколько будет стоить процесс передачи проекта в поддержку и развитие другой команде?
• Есть ли практика повышенных коэффициентов за срочность и как она используется?
• Что включает в себя гарантийное обслуживание и какие сроки решения гарантийных случаев?
• Зафиксированы ли в договоре цены для расчета стоимости работ и как происходит индексация?
• Какие этапы, по мнению исполнителя, могут быть наиболее дорогими?

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

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

С критерием качества, все намного сложнее: при разработке IT продукта, наиболее важным показателем качества является не только то, как это работает для конечного пользователя, но и то, что находится «под капотом». И пусть на первых этапах проекта ошибки проектирования, документирования, тестирования, процесса слабо осязаемы, на длинной дистанции, при развитии проекта - это может стать серьезной проблемой с дорогостоящими последствиями.

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

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

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

Буду рад ответить на любые вопросы в телеграм или комментариях.