Жизненный цикл разработки ПО

Сергей Ахметов

СТО <a href="https://talenttech.ru/">TalentTech</a>

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

Сергей Ахметов, СТО TalentTech, составил подробный чек-лист о том, как собрать команду профессионалов и какие шаги нужно пройти, чтобы создать продукт мечты.

Этап разработки. Где взять заказчика?

Когда человек основывает компанию, у него уже должны быть гипотезы о том, какие боли и задачи потенциального клиента его продукт призван решить. Либо у него есть ряд знакомых, которые четко говорят: «Если ты предоставишь мне такую услугу, я тебе готов заплатить». Это могут быть первые заказчики на момент рождения компании.

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

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

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

В любом проекте есть две роли product- и project- менеджер, на раннем этапе их может исполнять один человек.

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

Project-менеджер ведёт проект у конкретного заказчика и делает так, чтобы ваш продукт максимально удовлетворял уникальную потребность конкретного клиента. Его работа начинается с предпродажи, он управляет замыслом проекта, составлением ТЗ, ведёт шаг за шагом проектную работу и отвечает за конечное внедрение.

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

«Управление счастьем клиента». Способы организовать такой процесс

На этом этапе есть несколько уровней предложения.

Первый — стандартизированный пакет услуг, в рамках которого вы предоставляете SLA (Service Level Agreement), то есть соглашение об уровне обслуживания. В нем важно отметить, насколько быстро вы реагируете на запрос клиента, какой объем услуг можете оказать ему, что в этот перечень услуг входит. Обычно это чётко регламентировано и описано.

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

Исключаем ошибки при разработке

1. Самое первое и главное — не ошибиться в людях при найме. В разработке ПО единственно важный, стоящий и приносящий вам пользу актив — сотрудники. И на первых порах главное правильно их подобрать. Способы избежать ошибок в выборе команды:

• На первых этапах подбора нужно ответить себе честно на вопрос, обладаете ли вы необходимыми компетенциями, чтобы оценить профессионализм кандидата? Можете ли вы положиться на рекомендации знакомых, обладают ли они компетенциями в вашей сфере бизнеса? При подборе нужно разделять эмоции и факты – нанять обаятельного, но некомпетентного сотрудника будет ошибкой.
• Сделайте как можно короче цикл обратной связи в рабочих процессах. Не надо ждать месяц, чтобы определиться, подходит ли сотрудник вашей компании.Если у вас есть замечания к работе сотрудника и вы понимаете, что ожидали от него других результатов, сообщите ему об этом как можно скорее.Важно, чтобы сотрудники умели принимать обратную связь и реагировать на нее. Отсутствие этого дает понять, что в будущем с этим человеком не получится комфортной и продуктивной работы.
• Смотрите на профессиональные «маркеры», показатели, важные в конкретной области, чтобы понять, достигает ли сотрудник поставленных целей.В компании должна быть настроена система дефолт-менеджмента. На начальных этапах построения бизнеса она может быть в голове у руководителя, чтобы четко и беспристрастно оценивать, насколько команда справляется с задачами. Используйте готовые решения в случае выявления организационных барьеров, дефицита компетенций, низкой мотивации и вовлеченности и иных факторов, влияющих на производительность сотрудников.

2. Вторая ошибка при разработке — недостаточное внимание развитию сотрудников, их личному росту, вовлечённости, эмоциональному состоянию, производительности. Так как это ваш главный инструмент, нужно очень активно заботиться о том, чтобы он был в наиболее комфортном и производительном состоянии. В работе с адаптацией сотрудников и вовлечённостью помогают технологии: например, быстрые пульс-опросы позволяют понять настроение команды, выявить «боли» и провести аналитику, чтобы исправить процессы и повысить эффективность работы.

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

4. Следующая ошибка — неверные технические решения и накопление технического долга. Это могут быть решения, прекрасно функционирующие сейчас, но мешающие развитию в будущем. Например, нужно отправить клиенту при регистрации письмо, но текст записан в программный код и внести изменения в нем может только программист. Когда вы разрабатываете ПО, всегда есть выбор — сделать быстро или качественно, чтобы это в будущем не принесло проблем. Как правило, выбирается компромисс, и как бы вы не вели разработку, технический долг накапливается. Важно управлять этим процессом и вовремя ликвидировать неточности. Если об этих нюансах забыть, то через несколько лет компания может стать недееспособной.

5. Следующая возможная ошибка — игнорирование вопросов по управлению качеством. Качество — это то, что заставляет клиентов возвращаться к вам снова и снова. Недостаток внимания в этом вопросе обернется трудозатратами и потерями денег в будущем. Например, вы не написали тесты в коде, что сэкономило условный час времени. Через месяц, внося доработки, вы потратите день, чтобы убедиться, все ли корректно работает.

Финальный этап. Соблюдаем этапы разработки правильно

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

Второй источник — клиенты и их доработки. За этот этап отвечают project-менеджеры, они превращают желания заказчика в ТЗ.
Третья волна задач исходит от отдела разработки. Разработчики понимают, какой архитектурой или системами ответить на вызовы, которые ставят менеджеры и клиенты.

Три основных класса заданий сначала попадают в бэк-лог — общее хранилище всех задач. Бэк-лог анализируют product-менеджеры и project-менеджеры, выбирают самое важное и запускают в работу. Чтобы понять, какие задачи из бэк-лога нужно взять, команды договариваются о целях спринта. Этот процесс выглядит, как торг, так как учитывается множество мнений. Но никакого другого волшебного пути приоритизировать задачи не существует.

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

В качестве примера могу привести разработку продукта TalentTech.Обучение. Началось все с идеи: в процессе создания других продуктов мы поняли, что решений для быстрого выявления слабых сторон сотрудников и индивидуального обучения не так много, а комплексных — вообще нет. Затем, пообщавшись с потенциальными представителями ЦА продукта, выявили ключевые проблемы:

• Вовлечённость в образование. «Заказали лучшего тренера, организовали вебинар, но из 5 тысяч сотрудников пришли только 100».
• Скорость обучения. «Надо запустить продукт через неделю, а закончить через месяц».
• Управление обучением. «Хотим коррелировать образование с компетенциями, понимать, кому из сотрудников какой контент нужен».
• Аналитика по обучению. «Мы провели его и что дальше? Какой результат — непонятно».
• Контент. «Не знаем, где брать качественные и актуальные знания».

Проанализировав нужды ЦА, мы добавили вовлекающие механики и геймификацию, договорились с партнерами из университета «Нетология» о предоставлении контента под наше ТЗ.

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

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

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