Пошаговый разбор: как получить максимальный результат от работы с IT-подрядчиком?

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

Я более 10 лет я работаю с разными IT-компаниями в Украине, последние два года сотрудничаю с ЕРАМ в роли ведущего системного инженера. В этом материале постараюсь разъяснить потенциальным заказчикам, как остаться довольными сотрудничеством и продуктом, полученным от IT-подрядчика.

Кратко и по делу в Telegram

Вот реальный случай из моей практики. К IT-компании, которая занимается продажей и адаптацией самописной Content Management System-системы (это ПО на базе скриптов, которое позволяет управлять содержимым ресурса, менять его, просматривать и контролировать), пришел заказчик из сферы тяжелой промышленности. У него была интересная и вполне реализуемая идея: построить торговую площадку для продажи сырья и сопутствующих материалов. Присутствовало у клиента и техническое задание, в котором он описал свое виденье системы.

IT-компания с готовностью взялась за заказ и предоставила на подпись контракт: согласно документу подрядчик обязался работать над системой 100 часов. Время свыше указанного клиент должен был оплачивать дополнительно. Заказчик в эти детали не вчитывался, заплатил оговоренную сумму, а через 100 часов получил каркас CMS-системы с логином и парой таблиц — дашбордов. Чтобы реализовать описанное в техническом задании, заказчику надо было заплатить еще столько же. Это было неприятным сюрпризом.

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

Шаг 1. Детализация идеи

Большая идея клиента — это проект для IT-подрядчика. А у проекта есть начало и конец. Посмотрите еще раз на свое техническое задание: вероятно, не все указанные опции будут востребованы. Значит на их разработку не стоит тратить время и деньги. Также попробуйте применить принцип Парето к функционалу: что принесет вам максимальную окупаемость инвестиций? Оцените ROI (Return of investments).

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

Читайте также: Украинские айтишники соревнуются за возможность поехать на учебу в Кремниевую долину

Если готового решения на рынке нет — попробуйте выделить приоритеты. Подумайте, какие проблемы должен решать будущий онлайн-сервис/сайт/продукт (можно воспользоваться для этого Lean Model Canvas: в этой статье подробно описан процесс его создания). Привлеките к этой работе коллег. Независимо от позиции в организации это должны быть люди, понимающие ваши процессы и проблемы, которые хотите решить. Скажем, в фокусе — доставка товаров. Значит в вашей небольшой рабочей группе должен быть ведущий специалист по логистике.

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

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

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

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

Шаг 3. Будьте гибкими, но помните о правилах

Гибкая разработка — не значит бардак. Если вы с подрядчиком договорились о работе по Scrum, то приготовьтесь к определённым правилам и этапам:

• Scrum предполагает работу по спринтам: это "забеги" длительностью от одной до четырех недель;

• Также есть роли:

- команда разработки — самоорганизованная, кроссфункциональная группа из 5-9 человек, которая отвечает за разработку продукта, прогресс, результат и предоставление его клиенту;

- Scrum-мастер — работает с командой, организует совещания, повышает эффективность, помогает решать проблемы, следит за тем, чтобы процессы работали корректно;

- владелец продукта — он работает непосредственно с клиентом и осуществляет связь между ним и командой разработки, а также управляет ожиданиями, координирует и приоритизирует перечень задач;

Читайте также: В Киеве заключенные прямо из тюрьмы выманили у банка 1,4 млн грн, выдав себя за айтишников

• Регулярно в фокусе — три документа:

- бэклог продукта — единый ресурс с описанием требований для всех изменений в продукте;

- бэклог спринта — список задач на один "забег", который помогает команде сосредоточиться на цели;

- Sprint Burn Down Chart — диаграмма сгорания задач, по которой можно отслеживать текущий прогресс;

• Есть регулярные совещания:

- планирование спринта;

- ежедневный стендап (летучка);

- обзор спринта (итог "забега");

- ретроспектива (разбор полетов: что было хорошо, а что можно сделать лучше).

Схематично весь процесс выглядит примерно так:

К слову, заказчику полезно (но не обязательно) присутствовать на обзоре спринта. Так вы будете наблюдать развитие будущего сервиса в динамике. Один из главных плюсов гибких методологий — возможность влиять на процесс. В случае со Scrum вы можете договориться с владельцем продукта о производительности команды в каждый спринт (ее легко отследить по диаграмме сгорания задач). Оставайтесь вовлеченными, делитесь оперативно обратной связью, объясняйте свои ожидания и фиксируйте их "на бумаге".

Читайте также: МИД Беларуси возмутился продлением Украиной срока пребывания для белорусских айтишников

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

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

Источник