История о том, как мы практически с нуля запускали стартап, выстраивали в нем процессы, договаривались с нашим первым клиентом, про внезапно горящие сроки, и какие ошибки были допущены по ходу.
А так же на практических примерах и наших ошибках поговорим о плюсах гибких методологий управления проектами.
Кратко обо мне
Я Кирилл, на момент написания статьи имею опыт более 4х лет в роле руководителя it проектов. Работал над проектами по цифровизации и автоматизации производств, а так же имею обширный опыт работы в веб студиях. Подробнее в посте знакомства.
С чего все начиналось
Задолго до старта этого проекта я и мой партнер имели опыт работы на производстве в качестве R&D менеджеров. Компания была топ-1 в нише производства пластиковых изделий на лазерных станках. В наши задачи в том числе входило слушать лекции про lean и оптимизации(которые нам проводил спикер из BOSCH) и потом думать, как повысить эффективность производства за счет оптимизации процессов, уменьшения потерь и т.д.
В тот момент мы строили очень много процессов и я их очень сильно полюбил. Когда после долгого анализа проблем и не менее долгого поиска решения создавался или оптимизировался существующий процесс, который реально работал, исправлял обозначенные проблемы и добавлял прозрачности - это приводило меня в восторг.
В один момент мы столкнулись с проблемой: мы не знаем реальную эффективность нашего оборудования, а так же насколько его ресурс был использован. Так же мы не могли оценить какая может быть реальная максимальная производительность рабочих за станком.
Чем больше километров проехал автомобиль - тем ближе ТО. Так же и со станками: чем больше они отработали - тем скорее им будет необходимо обслуживание
Отсюда проблематично было составлять адекватное сменное задание. Тогда то мы и задумались о проведении цифровизации оборудования.
Пару слов про цифровизацию. Цифровизация - это процесс превращения аналоговых данных в цифровые. В нашем случае необходимо было перенести информацию о состоянии каждой единицы оборудования(время полезной работы, общее время работы и т.д.) в облако для удобного и понятного представления этих данных.
Мы быстро получили добро на проведение мероприятий по оцифровке т.к. владелец производства очень хотел, чтобы его производство было максимально технологичным. Быстро создав систему и интегрировав ее(тогда я активно изучал программирование и сам разработал MVP системы) мы увидели эффективность нашего оборудования и были мягко говоря огорчены. После этого мы начали активно оптимизировать процессы, связанные с работой за станком, по итогу подняв производительность оборудования в среднем на 40%. В будущем для разработки системы наняли программистов, а мне отдали руководство ими. Это был по факту мой первый опыт управления командой программистов.
Почему мы не купили готовое решение у компании, специализирующейся на цифровизации? Потому что решений, которые удовлетворяли бы наши потребности не было: они все были либо посредственного качества, либо были предназначены для других сфер(в основном нефтянка)
Пообщавшись с другими заводами мы обнаружили что они сталкивались с теми же проблемами, что и мы:
Отсутствие данных о реальной эффективности оборудования и процессов
Отсутствие информации о том, как использовать данные об эффективности для оптимизации процессов
Существующие на рынке решения не решали эти проблемы. И мы решили, что будем закрывать эту потребность. Мой коллега занялся поиском средств на разработку системы цифровизации, а я пошел прокачивать навыки управления it разработкой.
Старт разработки
Когда деньги на разработку были найдены, я определился с методологией в соответствии с которой будет идти разработка и составили дорожную карту проекта.
В качестве методологии управления проектом был выбран Waterfall. Соответственно roadmap проекта выглядел как-то так:
В тот моменты я не сильно любил гибкие методологии управления и соответственно не понимал какие плюсы они дают и в каких случаях было бы лучше отойти от старых подходов в пользу более новых(ну или хотя бы позаимствовать какие-то практики из них)
Пока мы собирали команду, параллельно общались с экспертами в области выстраивания процессов. Отталкиваясь от их экспертизы в вопросе “как должны работать производства” и понимания реальных потребностей производств мы определяли какой функционал необходим системе и составляли ТЗ. На ТЗ по итогу было потрачено около месяца, уточнено было все, что можно было уточнить. В нем даже были максимально подробно описаны функции, которые планировалось реализовать только через 3-4 месяца. Тогда мне казалось, что такое подробное описание поможет:
Точно определить сроки окончания работы над проектом
Качественно разделить работу на этапы
Лучше понимать по ходу разработки на каком этапе мы находимся и сколько осталось до конца
ТЗ было разбито на этапы, порядок этапов был выстроен относительно их приоритетности и логической обоснованности предыдущих этапов(хотя оглядываясь назад эта логичность была не везде).
Детальный план разработки платформы выглядел примерно так(оригиналы планов не сохранились):
Пока рисовался дизайн, первая задачка команде разработки была(ее краткая формулировка):
Придумать и описать API маршруты для ВСЕХ Функций платформы
Я думал что это упростит работу тк бэк-энд разработчик будет понимать, какие данные ему нужно отправлять, а фронт-энд - какие данные он будет получать и обрабатывать. На деле это заняло очень много времени и в будущем принесло много проблем т.к. по ходу многое менялось.
Я уже чувствую как руки тянутся написать комментарий и “прожарить” каждую строчку этого абзаца)
Разработка и первые трудности
Разработка шла достаточно плавно и по планам(как тогда казалось). Функция появлялась одна за одной. Из-за грамотной приоритезации бэклога одной из первой функций на платформе появились уведомления пользователя, хотя бизнес логика еще даже была не начата. Инвестора почему были не очень довольны тем, что за 1.5 месяца у нас на платформе были только уведомления. Они хотели видеть какой-то полезный функционал, который бы уже начал отображать ценность нашего решения. Но мы продолжили разработку в текущем темпе, убедив их в том, что в конце разработке и перед первой интеграцией они увидят функционал в полной мере.
Под конец апреля мы запустили в разработку электронику. Там так же был выбран классический подход к разработке. У нас были четкие требования к электронике, R&D там не было. Поэтому такой подход подошел на 100% и по понятному роадмапу мы все сделали в срок. Единственный момент, связанный с электроникой - стоит больше времени закладывать на тестирование и отладку. Но к этому вернемся позже.
Конкретной релиз-даты не было. Точнее она была, но мы ее придумали сами по логике: примерно в это время будет первая интеграция и к ней надо завершить разработку. Поэтому эта дата выглядела несерьезной и казалось, что времени на разработку еще много. Из-за этого контроль над разработкой немного ослабился, функции появлялись, но особо не тестировались. Да и в это же время мы с партнером были заняты переговорами с потенциальными клиентами и поэтому на проверку функционала времени не было. Визуально казалось что все ок, задачки двигаются, новые кнопочки на платформе появляются.
Первая интеграция
После долгих переговоров с клиентом мы определись с датой интеграции и она была запланирована… через 2 недели. Я сразу собрал команду и рассказал им эту крутую новость. После небольшого обсуждения мы начали проверять функционал платформы. И тут-то выстрелили все ружья, которые я заряжал по ходу статьи.
Состояние платформы было удручающим. Внешне все выглядело нормально и работоспособным, но:
Данные с телеметрии иногда не доходили до системы
Бизнес-логика неправильно рассчитывала метрики
Часть функционала работала только визуально
И многие другие проблемы. Я понимаю, что сроки переносить нельзя, потому что это очень сильно скажется на репутации компании. Надо было очень быстро исправлять ситуацию.
Как мы с этим справлялись
Первым делом я взял наше тз, разбил его на независимые блоки(фичи). Они были небольшими и для каждой фичи я сделал описание ее функционала и критерии приемки. Это было необходимо, чтобы мы понимали какой функционал у нас работает, корректно выполняет свою бизнес-функцию и готов к релизу, а какой требует доработки. Так получился бэклог. В бэклоге все задачи были в порядке их важности. В вверху - наиболее критические функции, внизу - менее важные(уведомления, часть настроек и т.д). Изначально мы обещали клиенту только основной функционал, поэтому от части второстепенных функций была возможность отказаться и реализовать их позже.
Далее изменился формат работы. Если раньше созвоны/встречи в офисе были раз в два дня, то теперь каждое утро был синк, и в течении дня как только функция была готова(или возникали какие-либо проблемы) мы созванивались, чтобы проверить ее работоспособность.
Никому не нравился микроменеджмент. Но я считаю, что это один из инструментов, которые может помочь исправить ситуацию в определенных случаях. Кризисная ситуация - один(и наверное единственный) из тех случаев.
Работать приходилось минимум по 12 часов, иногда задерживаясь до ночи. И тут уже появляется вопрос мотивации. Команда была на износе, поэтому приходилось чаще рассказывать про ее успехи, и постоянно напоминать что это - временно. Благо, проект был интересный, и все понимали что этот клиент станет нашим ключевым, поэтому шансов показать нерабочий продукт не было. Я понимал тогда и убежден до сих пор, что так выжимать команду просто недопустимо, но все же в случае, когда:
Горит дедлайны
Стратегически важный клиент
Нет возможности подключить доп. ресурсы к проекту
можно на относительно короткий срок воспользоваться переработками. Главное - не злоупотреблять этим и не иметь постоянной практики переработок. Это ни к чему хорошему точно не приведет.
Как-то занесло меня в одну веб-студию, где абсолютно нормальным считалось задерживать сотрудников на 2-3 часа сверх рабочего дня, заставлять работать дома в нерабочее время и на выходных. Итог был достаточно очевидный: проекты реализовывались плохо, сроки постоянно пропускались, клиенты были недовольны и большая текучка кадров. Начальство компании не видело в этом проблем и обвиняло во всем сотрудников. Когда я предлагал выстроить понятные и нормальные процессы, уйти от переработок и микро-менеджмента в ответ я слышал: “У нас и так все прекрасно, это вы ничего не умеете”. Надолго я там не задержался :)
Мы отключили почти весь функционал, и начали включать его по мере готовности. Таким образом после каждой фичи у нас был рабочий продукт с расширенным функционалом. Некоторые фичи занимали на доработку совсем немного времени, некоторые приходилось делать чуть ли не с 0. Данный подход позволил за две недели привести платформу к рабочему виду и все основные функции были готовы к работе. От части функционала, конечно, пришлось полностью избавиться, но они были не настолько критичны и появились бы в будущем с обновлением.
Команде потом был выдан недельный оплачиваем отпуск и премии.
Результаты такого подхода
Интеграция платформы не заняла много времени, с учетом установки сенсоров и телеметрии удалось внедрить все менее чем за неделю. Все работало исправно, что позволило успешно защитить эффект от решения перед всеми уровнями дирекции производства.
Кстати, помните я говорил, что под тестирование электроники надо закладывать больше времени? Так вот, где-то через 2 недели после интеграции датчики начали шалить, бывали моменты, когда данные не поступали по несколько часов. Проблема была решена изменением прошивки датчиков. Поэтому электронику надо тщательно тестировать на отказоустойчивость и продумывать механизмы, на случаи нештатного поведения
Как можно было бы избежать большей части проблем
Придерживаясь принципов Agile и используя гибкую систему управления управления проектом(в нашем случае подошел бы lean), большинства проблем не было бы. Обсудим это подробнее:
Отказаться от всеобъемлющего ТЗ. Стоило в общих чертах описать весь функционал, разбив его на фичи, где каждая фича закрывает какую-то конкретную проблему. Приоритизировать эти фичи по их ценности, и подробно описывать каждую непосредственно перед стартом ее разработки.
Непрерывная поставка результатов и тестирование. Если бы мы настроили процесс таким образом таким образом, чтобы после реализации нового функционала была возможность его сразу же проверить мы бы могли: быстро протестировать его, собрать обратную связь от фокус группы(ее тоже надо было бы собрать, но это не такая большая проблема) и быстро внести изменения/исправить проблемы. Так же это повысило бы понимание уровня реализации функционала, а ждать пока будет реализован вообще весь функционал.
Введение дейликов. Казалось бы очевидно, но давайте тоже вкратце об этом. Ежедневные созвоны на 10 минут позволили бы проговаривать возникшие проблемы и быстрее их решать и лучше понимать состояние каждой фичи. Все видели бы результат и продвижение в работе, а так же обстановка для обсуждения проблем мотивировала бы сотрудников говорить о них. Люди зачастую не хотят говорить о проблемах и пытаются решить их самостоятельно, хотя некоторые проблемы можно решить быстрее попросив помощи.
Не разделять разработку бэк-энда и фронт-энда, а ориентироваться на фичи. При раздельном подходе возникают проблемы несогласованности серверной логики и клиентской части. Разработка логики может разделяться на уровне подзадач. Разработчики должны вместе работать над реализацией фичей.
Общие выводы
Очень зря достаточно долгое время я недооценивал гибкие подходы к управлению проектами. Они действительно зачастую помогают лучше справляться с реализацией проектов. Но это не значит, что в 100% надо идти и внедрять себе scrum и говорить что мы теперь agile организация. Во первых скорее всего это не так потому что:
Невозможно моментально изменить процессы по которым вы работаете. Это достаточно сложный и долгий процесс.
Не во всех случаях это принесет пользу. Например при интеграции каких-либо готовых решений использование waterfall подхода будет рациональнее.
P.s. Это моя первая публикация, был бы рад получить обратную связь после прочтения и советы.
