5 ошибок, которых следует избегать при выборе исполнителя для своего IT-проекта

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

Поэтому, помните о распространенных ошибках и старайтесь не допускать их в своей практике.

1-я ошибка. Не проводить внутреннюю экспертизу проекта

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

Одна из самых больших ошибок в бизнесе – недостаточное внимание вопросам прогнозирования и планирования, которые являются исходными функциями в теории менеджмента (и на практике только доказывают свою эффективность).

Одна из самых больших ошибок при передаче проекта разработки информационной системы на аутсорсинг – не проводить внутреннюю экспертизу проекта.

Поиск технологического партнера необходимо начинать с проработки спецификаций и составления технического задания.

В общем виде, перечислим, основные моменты, на которые нужно обратить внимание:

  • Задачи и проблемы, которые данное приложение должно решить;
  • Функционал приложения;
  • Технологический стек (фронтэнд, бэкэнд, БД и т. д.);
  • Требования к качеству (функциональные и нефункциональные);
  • Сроки исполнения;
  • Ориентировочный бюджет.

2-я ошибка. Установить слишком жесткие рамки

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

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

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

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

3-я ошибка. Выбрать первую попавшуюся компанию

Общая идея здесь следующая: первое – не всегда самое лучшее. (Хотя это не абсолютная истина, и Вам может посчастливиться найти надежного партнера в лице именно самой первой компании, откликнувшейся на Ваш запрос предложений и цен).

Но, в целом, познание приходит через сравнение. Поэтому следует составить перечень ИТ-компаний откликнувшихся на Ваш запрос, а затем провести сравнительный анализ по каждой из них.

Как минимум, сравнение стоит производить по следующим критериям:

• Экспертиза в целевой области

• Продолжительность проектов

• Управление проектами, коммуникация

• Рейты компаний

Поясним поподробнее по каждому из обозначенных выше критериев:

  • Экспертиза в целевой области – здесь можно использовать такие показатели, как количество завершенных проектов в целевой области, а также мысли и идеи, которые они выражают относительно конкретно Вашего проекта во время обсуждения проекта;
  • Продолжительность проектов, которыми они занимались ранее – например, поможет понять, насколько Вы можете на них рассчитывать в долгосрочных проектах;
  • Управление проектами, общий подход к сотрудничеству и коммуникации – например, у многих компании (и наша в их числе) есть стандартная практика предоставления заказчикам ежедневных отчетов, еженедельных созвонов и т. д.;
  • Ну и, конечно, же, рейты компаний (при использовании оплаты по фактически отработанному времени) или расчетная стоимость проекта (при использовании модели контракта с фиксированной стоимостью).

4-я ошибка. Выбрать самую низкую ставку, чтобы сэкономить деньги

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

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

  • Компания – новичок на рынке или в данной нише. Она стремится завоевать доверие. Пока заказов не много. Так что ее единственный шанс – выиграть в ценовой конкуренции. Поэтому, выставляя низкие ставки, она стремится обеспечить необходимую загрузку, чтобы, как минимум, выйти на окупаемость. Кстати, если это амбициозная компания с далеко идущими планами, то в команде у нее вполне могут оказаться мидлы и сениоры, т. е. разработчики с неплохими компетенциями и опытом. В общем, если посчастливится найти такую компанию, то, нужно, конечно, брать.
  • Команда разработчиков, которая будет работать над Вашим проектом, в большинстве своем – джуниоры (студенты последнего курса или недавние выпускники), еще не имеющие опыта и готовые работать за небольшую плату, чтобы набраться опыта. Логично, что зарплата таких специалистов небольшая, что позволяет компании выставлять низкие рейты. Однако, обратной стороной медали является низкая экспертиза команды в целом, и, следовательно, велики риски того, что реализуемые решения будут неоптимальными, архитектура – не продумана, код – такой, что без слез не взглянешь, а само приложение – неэкономично, неподдерживаемое и т. д. Еще из рисков можно добавить вероятность того, что сроки выполнения проекта будут чрезмерно затянуты. И даже есть риск срыва проекта. В общем, сложные проекты лучше точно не отдавать.
  • Это приманка, чтобы поймать Вас на контракт. А потом попытаться раскрутить бюджет дополнительными задачами по более высоким ставкам (загнав в lock-in), выставлением счетов с большим количеством человеко-часов, чем требовалось на выполнение работы и т. д.

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

Вспомним знаменитое «Быстро. Дешево. Качественно. Выбирайте любые два».

5-я ошибка. Не проверить уровень технологической экспертизы разработчиков

Купите ли Вы автомобиль, просто поверив продавцу на слово, что это идеальный выбор? Нет, конечно! Для этого и существуют тест-драйвы. По крайней мере, нужно хотя бы оценить управляемость автомобиля и его комфортность именно для Вас.

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

Несколько примеров того, что может вскрыться при тестировании экспертизы команды:

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

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

• Ребята оказались немного ленивыми, чтобы запускать реальные тесты.

Поэтому рекомендуем не рисковать, а протестировать своего потенциального технологического партнера. Особенно, если речь идет о заключении крупного долгосрочного контракта.

Варианты могут быть следующие (естественно, в зависимости от того, насколько это осуществимо для каждого конкретного заказчика):

  • Пилотные проекты (как правило, это небольшой отдельный проект, но бывают такие варианты, как создание небольшой отдельной функции по текущему проекту);
  • Рефакторинг имеющегося легаси-приложения или его части (при условии, что используемые технологии в большинстве своем идентичны тем, которые будут задействованы на основном проекте);
  • Тестовые задания (это может быть и написание куска кода, и даже аудит кода с формированием перечня пунктов к исправлению);
  • Челленджы с GitHub и т. д.

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

Вместо заключения

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

0
Комментарии
-3 комментариев
Раскрывать всегда