Comments 9
Дом стоит построить от 1000р и в гору. Правда домик будет игрушечный и из картона. А за миллионы можно построить соответствующий дом. Автор удивляет тем, что так и не отвечает на вопрос темы, а попросту рассусоливает на тему управленчества и менеджмента. А автор знает, что если в проекте выкинуть к чертям 2/3 управленческого состава, то проект будет работать быстрее и лучше? И фактор "ощущения нужности путём общения с руководством" — в российской действительности, по-прочту бред сумасшедшего. Так как в руководящие должности в основном "подтягивают". Для какой компании написана эта статья? 100 человек? 500 человек? На 1000? Где вы видели возможность бесконечно назначать кучу управленцев в фирме на 8-12 человек? Вам вроде задали конкретный вопрос по технической реализации проекта. А вы всё сложили на управление. Я тут давеча столкнулся с подобным решением проблемы. Нанята куча управленцев, назначены должности, прописаны планы, документация, и т. п. Но когда вопрос доходили до воплощения в жизнь — был несколько другой подход, а именно: "я поставил задачу — выполняйте". Реально как во всех крупных фирмах. Только вот вопрос именно технической реализации отсутствовал от слова совсем. Поэтому бумаги было много, а эффекта мало. И бумаг именно по технической составляющей никто не писал. Ибо это было сложно и неблагодарно, а самое главное — бессмысленно. И поскольку непосредственный исполнителей проекта привлекли к написанию планов, карт, саппорта ещё не готовой продукции — проект попросту встал. Потом руководство о думалось, выкинул 2/3 управленцев к чертям и дало возможность пахарю — пахать, а столяру — творить. И проект пошёл. Постепенно роли распределили сами, саппорта организовался небольшими силами, а репозитории и документация собралась из заметок и глобального плана.
Если для роста продаж зерна надо пахать больше земли — значит, надо пахать, а не описывать, без сомнений. А если надо держать SLA на 5 девяток — надо строить operations и писать процедуры.
Ответ на вопрос «зачем?» требует описание бизнес-логики. Простите, не могу раскрывать детали конкретных ситуаций.
Однако, в том или ином виде описанная ситуация возникает из года в год. Суть всегда одна — условия сильно изменились, и проект не справляется с задачами. Вариации описанной ситуации я встречал и в проектах с двумя разработчиками, и с пятью сотнями, и смог решить проблемы в некоторых из них.
В заметке я пытаюсь объяснить какие именно проблемы решаются методиками, в каких ситуациях процессы будут полезны, а в каких — бессмысленны.
С ситуацией — «условия сильно изменились, и проект не справляется с задачами» можно справиться не расширяя проект, а наоборот дробя. Вот вам проект на два — бек и фронт. А можно еще по смысле mvc/mvp/mvvm и прочее. Дальше больше — делите на модули. Потом на микросервисы. Все это поможет распределить людей так, чтобы они максимально быстро работали друг с другом. Никакой scrum/agile не даст столько производительности двум фуллстекам как сочетание отдельного человека на бек и на фронт.
Ваше решение тоже рабочее, но очень дорогое. Десять разработчиков со средней зарплатой это уже миллион в месяц.
Ну а теперь по пунктам
- Параметры, которые влияют на продажи: мне как разработчику все равно. Пока код хороший я им горжусь, если бизнесу нужно быстрее чем качественней, то я начинаю ненавидеть все.
- Документация, проект пиленый левой пяткой доку имеет такую же. Просто потому что не получится хорошо структурировать знания о неструктурированном коде. Плюс доку не читают. На нее спихивают причины: «А этого в доке нет, поэтому задача не сделана»
- Определись проблемы с масштабированием и доступностью. Весь код. Он сделан левой пяткой, так что весь.
- Согласовать среднесрочные цели IT-команды с высшим руководством. Работа менеджера, хотя для проекта с таким легаси первые три месяца уйдут на мелкие текущие задачки, просто чтобы понять что и где. А потом рефакторинг или вообще написание с нуля.
- Доска, трекер, мессенджер, репозиторий. Перед тем как все это создавать лучше проект поделить. Тогда взаимодействовать придется реже. Конечно без этой фигни обойтись нельзя, но как же иногда бюрократизация процессов их тормозит. Сначала лучше действовать быстро. Все перечисленные инструменты — должны решать ваши проблемы, а не абстрактные, бывающие у любой команды.
- Процесс найма и вхождения в проект новых разработчиков. Наверное стоит, но только когда будет понятно на что этого разработчика посадить. Ответ: «у нас на доске много не выполненных задач» — не принимается. Большая часть этих задач не сделана из-за того что их делают несколько человек. Добавление к ним еще одного может замедлить процесс, а не ускорить. Впрочем иногда новые люди нужны. Да и страховка от внезапного ухода лишней не будет. Но это не приоритетная задача.
- Наладить системы мониторинга и бекапа. Гуд. Правда тут как раз — нанять админа/девопса. Это вполне может сделать аутсорсер, причем даже за менее чем за неделю.
- Сделать декомпозицию среднесрочных задач по этапам и написать календарный план. От и до ненужная фигня. Точнее нужная только менеджерам. Плюс чревато тем, что вместо того чтобы давать полную задачу вы дадите разработчику часть. В результате процесс замедлится. Зато вы оградите себя от случаев, когда разработчик долго делает ненужную фигню. Проблема в том, что не все задачи можно быстро декомпозировать. И не все можно декомпозировать так, чтобы получить ускорение давая нескольким разработчикам.
- Сделать CI/CD. Тут нужно смотреть по ситуации. Чем чаще апдейты, тем чаще они не нужны пользователям. Посмотрите на винду, там каждую вторую версию не любят. А уж частые апдейты десятки режут все кому не лень. Даже хром наваливает апдейты раз in six weeks. Я понимаю что бизнесу нужно быть гибким. Однако это не значит, что пришедшая на выходных менеджеру идея — не отпугнет клиентов. Даже если эту идею он получил из обратной связи. Короче помните, что все новые фишки вполне могут подождать полтора месяца.
- Написать план изменения архитектуры. Гуд. Ну или план написания приложения с нуля.
- Выставлять приоритеты задачам в беклоге. А чтобы разработчики смотрели на это сделать зависимость их зарплаты от приоритетов задач. Есть всего три приоритета 1 — если нечего делать, 2 — в порядке очереди, 3 — срочно и вообще вчера. Для первого можно отдельную доску, впрочем задачи первого типа часто можно по формулировке отличить или по дате, и вообще их не делают. Для второго обычная доска. Третий, срочный тип задач, почему-то сообщают лично, и вообще о нем напоминают, интересно почему?).
- Наладить регулярные встречи IT-команды с продактом и отчеты высшему руководству. Дело хорошее. Правда почему-то программисты его не любят. Наверное потому, что чаще руководство не дотягивает до руководства оракла. В тяжелых случаях сложно слушать как человек, что часто бухает, матерится, курит, и т.д. выплескивает тебе обвинения и указания. Для этого нужны менеджеры. Чтобы программисту не нужно было быть сресоустойчивым.
В общем по большей части ваши советы заменяются — нанять пм-а, нанять админа, посмотреть насколько получится раздробить частей, начать дробить. Потом уже нанимать бека, фронта, человека сопровождающего модуль отслеживания плюмбусов.
Процессы разработки, или сколько стоит сделать сайт