Comments 19
В итоге мы вышли на состав из 17 человек:
10 бэкенд-разработчиков
2 фронтенд-разработчика
Владелец продукта
2 аналитика
Архитектор
DevOps
Менеджер проекта
Что-то не сходится: как ни считай, получается 18 человек
Смущает несколько моментов:
бизнес логика оказалась размазана по всему приложению, а вместе с ней и сами задачи стали сильно связаны друг с другом.
Предполагаю, что теперь при доработки продукта будут сложности.
Запуск системы на фабриках команда провела уже без моего участия. И это для меня главный показатель качества моей работы.
Странно, что вы не довели проект до конца. В статье ничего не сказано насколько в итоге продукт получился качественным и удовлетворяющим ожиданиям заказчика
Перед запуском мы столкнулись с проблемами нагрузки. В это время я прилетел в Ставрополь к партнёру, и вместе с ним нам удалось собрать окружение для нагрузочного тестирования. Мы нагрузили систему уже имеющимися сценариями запросов и смогли воспроизвести проблему.
Каким образом вы столкнулись с проблемами нагрузки до нагрузочного тестирования и как вы решили саму проблему?
Сложность системы высокая. Даже при обычном тестировании вылезли недочеты, которые перегрузили БД. Что-то исправили быстро - убрали middleware, которая много записей в БД создавала. С чем-то нужно было повозиться - понять как оптимизировать работу Joeflow-Dramatiq-RabbitMQ. Там материала на отдельную статью.
Оказалось, что junior-разработчики могут быть даже продуктивнее, чем middle-разработчики. Да, им может не хватать знаний, но они компенсируют это вовлечённостью и интересом.
К сожалению, не все умеют и хотят работать с начинающими специалистами
Таким образом, у нас были суперпродуктивные ежедневные встречи продолжительностью 10–30 минут, даже при максимальном размере команды в 18 человек. Единственное важное правило — следить за тем, чтобы диалоги выносились на отдельные встречи.
Можно ли прояснить, зачем всем 18 сотрудникам слушать беседу о проблеме, в которой задействовано 2-3 человека? И при каком размере команды это правило перестает работать?
Тут скорее вопрос зачем людям работающим над общим проектом регулярно собираться вместе. Если мы зафиксируем формат "слушать беседу о проблеме, в которой задействовано 2-3 человека", то он действительно только отторжение вызовет.
Я думаю на 18 человек сработало, потому что за пол года у нас сформировалась культура коммуникаций, список негласных правил - о чем говорим, о чем не говорим и когда заканчиваем встречу.
Плюс этот формат работает, в том числе, потому что команда распределенная. Люди находятся в разных часовых поясах от Новосибирска до Калининграда. Есть понятное время в котором можно быстро озвучить вопрос и запланировать встречу.
Определение формата встречи - это все в полномочиях команды. Формат перестает работать когда команда считает что встреча прошла непродуктивна - этот критерий лучше чем количество людей.
18 тел два года писали хз что хз для чего и с хз каким результатом?
Спасибо, интересная статья.
Вопросы, для лучшего понимания:
Правильно ли я понял, что итог двух лет - это собранная команда по поддержке и доработке запущенного проекта (которая дальше будет жить без участия автора)?
Т.е., в частности, - грейды нужны уже на этап после запуска?
По "текущему раскладу" - я так понял, что грейдапы в созданной команде приветствуются. А есть ли ограничения (в пределах какого-то общего бюджета проекта, по установленным заранее квотам, по готовности заказчика)? Могут ли потенциально при такой схеме получиться оверквалы? Если да, что с ними предполагается делать?
Правильно ли я понял, что итог двух лет - это собранная команда по поддержке и доработке запущенного проекта (которая дальше будет жить без участия автора)?
Да, все верно.
Т.е., в частности, - грейды нужны уже на этап после запуска?
Грейды нужны стали уже в процессе, чтобы:
отвечать на вопрос разработчиков - что им нужно чтобы повысить свою зарплату
соотнести оклады с рынком
и, пожалуй самое главное, показать путь развития для каждого инженера в рамках компании. Наметить цели полезные для компании, а не только цели "вырасти в синьора, чтобы получать на рынке труда больше денег"
Оверквалы - это хорошая проблема, чтобы ее решить. :)
Там есть большие возможности для карьерного роста. Скажем можно вырасти в solution architect, который прорабатывает решения для новых фабрик на пресейле.
Почему вы оцениваете проделанную работу как успех, если не описан результат внедрения? Как ваша система повлияла на работу фабрик? Дашборд тоже странный, какая разница, сколько там запросов внутри MES системы случается, если производство стоит?
Реальное производство - это же очень круто. А уж MES, которая является нервной системой фабрики/завода - это действительно интересная разработка, которая имеет очень много своих особенностей. И, по сути, интересная часть только началась после первого внедрения. На какие метрики в итоге смотрите? Как команда взаимодействует с персоналом фабрик? Как решаются вопросы UX, а как вычисляются узкие места и проблемы производства, которые могла бы решить MES? Если производство круглосуточное, как организовано дежурство группы эксплуатации, да и в целом взаимодействие с командой эксплуатации производства?
Почему вы оцениваете проделанную работу как успех, если не описан результат внедрения?
Мы заменяем уже готовую систему. Практически безшовно. То есть автоматизация уже достаточно глубокая и задачи углублять ее нет. Есть задача перейти на новую систему с минимальным простоем и с оперативным решением текущих проблем.
На нескольких фабриках система уже запущена.
по сути, интересная часть только началась после первого внедрения
Я создал отдел разработки для интегратора, который уже много лет настраивает производственные линии, внедряет разные модули MES системы на этих фабриках. Первое внедрение произошло много лет назад, как и выстраивание взаимодействия с персоналом. Там моей помощи не требуется. А если бы и требовалось... Дело в том, что взаимодействие с такими крупными концернами никогда не выноситься в публичное поле.
Если производство круглосуточное, как организовано дежурство группы эксплуатации
Производство круглосуточное. С нашей стороны есть дежурство по сменам. 2ое дежурных на линии первой поддержки. Есть мобильный телефон, внутренная система тикетов(а-ля Zendesk), но у нас есть рабочие чаты и бОльшая часть вопросов решается там.
Создание сложной IT-системы и отдела разработки: мой путь