Контекст

Ко мне обратились с запросом помочь вывести из кризиса проект по заказной разработке софта.

Ситуация была следующая. Есть Исполнитель — компания, специализирующаяся на заказной разработке. Есть Заказчик — строительная компания, которая на новом для себя рынке (Казахстан) выиграла тендер на крупную стройку. Есть Посредник — айти-компания, которая свела И и З, и являлась юридической и финансовой прослойкой.

Софт, который заказали исполнителю — система для проведения тендеров на закупку материалов и услуг.

Важные моменты:

1. Закупки должны были начаться через полгода после старта проекта по разработке; старт, условно, был в июне, закупки должны были стартануть в декабре
2. Начальная позиция заказчика была такая: «нам нужен не исполнитель по ТЗ, а консультант, который сможет наладить не только софт, но и процесс, сразу в цифре, вопреки сопротивлению на местах»
3. Структура контракта — два модуля, на реализацию каждого примерно по полгода, стоимость каждого — примерно 150 тыс. долларов.
4. Контракт был фиксовый и с сильным перекосом в пользу заказчика: деньги и срок сдачи жестко закреплены, скоуп накидан тезисно (ТЗ и описанного процесса нет), исполнитель дал скидку.
5. Директор компании-исполнителя рассказывал, что у Посредника есть личный контакт учредителя Заказчика и можно считать его нашим проектным чемпионом, который продавит любое грамотное решение
6. Описания процесса проведения тендера не было ни в каком виде
7. Системное окружение — 1С: ERP как основная система (была у Заказчика, нужно доработать), Личный кабинет поставщика (веб-сервис, нужно разработать).

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

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

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

1. Команда собрана и укомплектована, зарплаты платятся вовремя. В команде 9 человек: дизайнер, фронтендер, бэкендер, аналитик бизнес-процессов, два аналитика 1С, разработчик 1С, основной РП (тот самый, которым недовольны, внешник), младший РП (сотрудник команды Исполнителя, который недавно подключился для помощи основному РП).
2. Основные контактные лица на стороне Заказчика — аналитик бизнес-процессов (внешник, был нанят под проект), руководитель одного из отделов.
3. Прошло 3 месяца из 6 заложенных на первый модуль.
4. Разработана основа ЛК Поставщика — можно зарегаться, завести компанию, завести сотрудников.
5. Основная система (1С: ERP) стала доступна для анализа функциональных разрывов неделю назад.
6. РП не наладил операционку и стандартные проектные ритуалы, демотивировался и демотивировал команду.
7. Требования собираются несистемно, плохо документируются, скоуп проекта (и без того невнятный) раздулся из-за бесконтрольного добавления хотелок и задачек заказчиком.
8. Работа документируется в Outline, таски в Yougile.
9. Нет описанного процесса — ни as-is, ни to-be; есть пара огромных bpmn-схем, непонятных без объяснения автором.
10. Нет понимания, каковы вообще границы первого модуля.
11. Самое важное: нет критериев успешности модуля, не определена процедура сдачи. Короче, непонятно, кто и в рамках какой процедуры со стороны клиента скажет «все ок, принимаем, завтра оплатим».

Освобождаем основного РП от обязанностей, идем разбираться с целевым процессом.

Шаг 1: изучаем ситуацию

Первым делом изучили bpmn-схемы и доступные постановки. Постановки состояли из блок-схем и коротких описаний в странном формате. Оказалось, аналитик команды был на самом деле аналитиком бизнес-процессов и изначально пришел нарисовать to-be-процесс и согласовать его с клиентом. А нужен был инженер по требованиям или хотя бы бизнес-аналитик.

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

Плохо: команде описания от аналитика были непонятны, поэтому на обсуждение «постановок» уходила масса времени. Ситуация осложнялась тем, что аналитик не понимал, как правильно собирать, обрабатывать и передавать команде требования и сценарии. Составляем список ролей/стейкхолдеров — они недопредставлены: не были проведены интервью с закупщиками и сотрудниками службы безопасности, при этом их работа в системе подразумевается.

Постановки были вот в таком формате, страниц на пять

Увольняем аналитика, привлекаем двух других (у Исполнителя были в запасе внешники), разрабатываем мануал по постановке на разработку. Пробуем на паре задач — команде подходит, отдаю аналитикам, сам контролирую итоговые постановки.

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

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

Параллельно кидаем все усилия на анализ 1С — нужно срочно понять, какой там предстоит объем работы.

Шаг 2: пускаем пыль в глаза и пересобираем план

Примерно через неделю после начала нашего сотрудничества был запланирован очередной демо-звонок для Заказчика. Участники — ген. директор, рук. департамента, рук. отдела. Цель — показать результаты работы за месяц.

Демо-сценарий выглядит бледно: полторы фичи, в демонстрации сценарий с ними проходит за пять минут. Заказчик будет недоволен, особенно учитывая растущий негатив к результатам и темпу разработки в целом. Принимаем решение в быстром режиме нарукожопить 2-3 фичи из бэклога, на моках, чтобы демо выглядело получше. Это манипуляция и пыль в глаза, но другого способа снизить потенциальное недовольство заказчика сходу придумать не получается.

Очень быстро пилим эти фичи, очень быстро тестим и доводим до ума, выносим на демо. Замечаний (помимо «давайте быстрее») нет, привычно просят немного поиграть шрифтами, потому что ui should be more friendly and appealing.

Результат хороший: во-первых, выиграли немного времени — можно пересобрать план; во-вторых, проверили команду на возможность быстрых итераций и команда справилась.

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

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

Созваниваемся с Заказчиком, принимаем решение: не делать процесс аккредитации и рабочее место службы безопасности в контуре 1С, вынести в веб. Так нас не держит 1С и мы можем разработать, протестировать и сдать клиенту этот сценарий на 80% чисто на вебе. Остальные 20% — это интеграция и передача статуса аккредитации в 1С, их придется доделать потом.

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

Прогнозируем, что к следующему демо у нас будет реализовано как минимум два больших сценария. Этого будет достаточно для демонстрации на троечку, если дела с 1С продолжат идти так же медленно. Жопу минимально прикрыли, записали себе в список хороших дел реализацию админки — Заказчик думал, что она появится гораздо позже.

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

Из прочего:

• Налаживаем управление — вводим спринты и связанные ритуалы
• Перестаем принимать «хотелки» клиента сразу как задачи; вводим процесс фиксации «хотелок» с шагами «пожелание → анализ → решение», делаем табличку в эйртейбле, настраиваем формочку — теперь все пожелания представители Заказчика будут писать в нее; он пишет, мы читаем и анализируем, уточняем подробности и далее решаем, как быть
• Наконец-то разбираем основной процесс: по сути, это движение одного большого документа «Запрос цен» по статусам; на каждом статусе документ обогащается новой информацией и рассматривается разными группами стейкхолдеров.

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

Резюме — принятые решения

Проблемы: проект фиксовый; половина срока прошла, а работы сделано около 10-15% от общего объема; непонятно, что именно делаем — а значит, будут проблемы со сдачей; команда работает стихийно; 1С стала доступна только неделю назад.

Команда

1. Уволить РП и аналитика; взять другого аналитика на замену, т. к. с требованиями беда
2. Поменять роли: младший РП берет на себя операционку и ежедневную рутину, консультант-РП берет на себя архитектуру управления проектом

Метод работы

1. Меняем подход к сбору и описанию постановок на разработку — переходим на структуру «контекст, сценарии, требования»
2. Меняем подход к сбору пожеланий заказчика — переходим на сбор в форму, последующий анализ и обсуждение; если новое пожелание заказчика очень нужно — договариваемся что-то убрать из бэклога или делать в рамках отдельного бюджета
3. Вводим работу по спринтам и связанные ритуалы: пленнинг, груминг, дейли, демо.
4. Вводим обязательные протоколы встреч с представителями Заказчика с фиксацией в Outline.

План работы

1. Чтобы перестройка плана и перемены в команде были восприняты хорошо — поспешно доделываем пару фичей для включения в демо заказчику
2. Пока нет ясности с 1С (идет анализ) — выносим один из сценариев в веб-часть, чтобы точно исключить ее из скоупа 1С
3. Решаем сделать админку — это не вредит критическому пути, зато делает Заказчика счастливее.

Ошибки

1. Мы не остановили разработку и анализ до выяснения важных обстоятельств: хватит ли оставшегося времени на разработку всего запланированного; кто и как будет принимать работу в конце первого модуля.
2. Мы не запустили обсуждение по увеличению срока разработки на 1-2 месяца из-за недоступности 1С. Это сильно навредит Исполнителю ближе к концу разработки первого модуля.

Конец первой части.