5 ошибок, которых следует избегать при выборе исполнителя для своего IT-проекта
Выбор исполнителя для своего IT-проекта – задача не из простых. На кон поставлены большие бюджеты, зачастую, успешность закрытия вопросов в рамках отдельных бизнес-процессов, реже (но все же встречается) – репутация организации или ее бесперебойное функционирование в целом. Допустите ошибку при выборе команды, которой будет передан проект, и может возникнуть масса проблем, на решение которых будет потрачено дополнительные средства и время.
Поэтому, помните о распространенных ошибках и старайтесь не допускать их в своей практике.
1-я ошибка. Не проводить внутреннюю экспертизу проекта
Одна из самых больших ошибок в повседневной рутине – ходить по магазинам, не имея четкого списка покупок и понимания, сколько денег есть в кошельке. (Про деньги в кошельке в век кредитных карт – это уже больше аллегория, конечно, но общая идея ясна).
Одна из самых больших ошибок в бизнесе – недостаточное внимание вопросам прогнозирования и планирования, которые являются исходными функциями в теории менеджмента (и на практике только доказывают свою эффективность).
Одна из самых больших ошибок при передаче проекта разработки информационной системы на аутсорсинг – не проводить внутреннюю экспертизу проекта.
В общем виде, перечислим, основные моменты, на которые нужно обратить внимание:
- Задачи и проблемы, которые данное приложение должно решить;
- Функционал приложения;
- Технологический стек (фронтэнд, бэкэнд, БД и т. д.);
- Требования к качеству (функциональные и нефункциональные);
- Сроки исполнения;
- Ориентировочный бюджет.
2-я ошибка. Установить слишком жесткие рамки
Разработка программного обеспечения — это не фармацевтика. Здесь нет строгих рецептов, которым нужно следовать. Другими словами, при планировании необходимо оставлять место для изменений, дополнений и т. д. Как по технологиям, объему проекта, так и, как следствие, по бюджету.
Например, разработчики, основываясь на своем опыте, могут предложить использовать другую технологию. И эта технология позволит, например, обеспечить более высокий уровень производительности, безопасности или масштабируемости. Также, в ходе реализации проекта может возникнуть потребность в дополнительном функционале. Наконец, что особенно важно, разработка программного обеспечения на заказ не дает гарантий, что Вы уложитесь в бюджет, указанный Вами изначально (например, см. предыдущие два пункта, обсуждавшиеся в этом абзаце).
Другими словами, будьте гибкими и открытыми для обсуждения, но при этом сохраняйте бдительность и просчитывайте экономику.
3-я ошибка. Выбрать первую попавшуюся компанию
Общая идея здесь следующая: первое – не всегда самое лучшее. (Хотя это не абсолютная истина, и Вам может посчастливиться найти надежного партнера в лице именно самой первой компании, откликнувшейся на Ваш запрос предложений и цен).
Но, в целом, познание приходит через сравнение. Поэтому следует составить перечень ИТ-компаний откликнувшихся на Ваш запрос, а затем провести сравнительный анализ по каждой из них.
Поясним поподробнее по каждому из обозначенных выше критериев:
- Экспертиза в целевой области – здесь можно использовать такие показатели, как количество завершенных проектов в целевой области, а также мысли и идеи, которые они выражают относительно конкретно Вашего проекта во время обсуждения проекта;
- Продолжительность проектов, которыми они занимались ранее – например, поможет понять, насколько Вы можете на них рассчитывать в долгосрочных проектах;
- Управление проектами, общий подход к сотрудничеству и коммуникации – например, у многих компании (и наша в их числе) есть стандартная практика предоставления заказчикам ежедневных отчетов, еженедельных созвонов и т. д.;
- Ну и, конечно, же, рейты компаний (при использовании оплаты по фактически отработанному времени) или расчетная стоимость проекта (при использовании модели контракта с фиксированной стоимостью).
4-я ошибка. Выбрать самую низкую ставку, чтобы сэкономить деньги
Скупой платит дважды. Это абсолютная истина в любой сфере нашей жизни. Как правило, качество товаров и услуг, в том числе услуг по разработке информационных систем, находится в тесной корреляции со стоимостью данных услуг.
Давайте подумаем, как появляются эти чрезвычайно низкие ставки. Вот некоторые из причин, которые могут иметь место быть:
- Компания – новичок на рынке или в данной нише. Она стремится завоевать доверие. Пока заказов не много. Так что ее единственный шанс – выиграть в ценовой конкуренции. Поэтому, выставляя низкие ставки, она стремится обеспечить необходимую загрузку, чтобы, как минимум, выйти на окупаемость. Кстати, если это амбициозная компания с далеко идущими планами, то в команде у нее вполне могут оказаться мидлы и сениоры, т. е. разработчики с неплохими компетенциями и опытом. В общем, если посчастливится найти такую компанию, то, нужно, конечно, брать.
- Команда разработчиков, которая будет работать над Вашим проектом, в большинстве своем – джуниоры (студенты последнего курса или недавние выпускники), еще не имеющие опыта и готовые работать за небольшую плату, чтобы набраться опыта. Логично, что зарплата таких специалистов небольшая, что позволяет компании выставлять низкие рейты. Однако, обратной стороной медали является низкая экспертиза команды в целом, и, следовательно, велики риски того, что реализуемые решения будут неоптимальными, архитектура – не продумана, код – такой, что без слез не взглянешь, а само приложение – неэкономично, неподдерживаемое и т. д. Еще из рисков можно добавить вероятность того, что сроки выполнения проекта будут чрезмерно затянуты. И даже есть риск срыва проекта. В общем, сложные проекты лучше точно не отдавать.
- Это приманка, чтобы поймать Вас на контракт. А потом попытаться раскрутить бюджет дополнительными задачами по более высоким ставкам (загнав в lock-in), выставлением счетов с большим количеством человеко-часов, чем требовалось на выполнение работы и т. д.
5-я ошибка. Не проверить уровень технологической экспертизы разработчиков
Купите ли Вы автомобиль, просто поверив продавцу на слово, что это идеальный выбор? Нет, конечно! Для этого и существуют тест-драйвы. По крайней мере, нужно хотя бы оценить управляемость автомобиля и его комфортность именно для Вас.
Также Вы не должны заключать контракт на разработку, не протестировав навыки и экспертизу потенциальных разработчиков. Ведь слова — это только слова.
Поэтому рекомендуем не рисковать, а протестировать своего потенциального технологического партнера. Особенно, если речь идет о заключении крупного долгосрочного контракта.
Варианты могут быть следующие (естественно, в зависимости от того, насколько это осуществимо для каждого конкретного заказчика):
- Пилотные проекты (как правило, это небольшой отдельный проект, но бывают такие варианты, как создание небольшой отдельной функции по текущему проекту);
- Рефакторинг имеющегося легаси-приложения или его части (при условии, что используемые технологии в большинстве своем идентичны тем, которые будут задействованы на основном проекте);
- Тестовые задания (это может быть и написание куска кода, и даже аудит кода с формированием перечня пунктов к исправлению);
- Челленджы с GitHub и т. д.
Очевидно, что первые два варианта являются наиболее информативные с точки зрения оценки реальных компетенций. Однако, они же являются длительными и наиболее дорогостоящими, так как предполагают реальную оплату за проделанную работу.
Вместо заключения
Кстати, скорость и полнота отклика компании на Ваш запрос также могут поведать много интересного о компании. Например, если компания медлит с откликом на Ваш запрос, будут ли ребята более активны в коммуникации непосредственно при работе над проектом? Поэтому, поведение исполнителей в процессе сбора предложений – тоже немаловажный аспект, который косвенно может охарактеризовать надежность компании.