Эта статья будет о наболевшем. О правилах в разработке и что бывает, когда их нет.
Она не совсем про Руководство проектами, она пошире: про руководство командами разработки. Но если вы Руководитель и у вас на проекте разработки ПО есть хотя бы пара разработчиков, вам ее будет полезно прочитать.
Эта статья – часть цикла статей о том, чего не рассказывают на курсах РП, и что в жизни понадобится вам с первого же дня работы: о так называемых софтскиллах РП. Кому это интересно, читайте статьи здесь и заходите в мой ТГ канал «Морковка спереди, морковка сзади».
Правила – это скучно.
Я давно заметил, что, когда набираю новых менеджеров и рассказываю им про регламенты и правила разработки в компании, они очень внимательно слушают, усиленно кивают и вообще – само внимание. А спустя пару недель или месяц, внезапно выясняется, что они не даже не кликнули по ссылке, которую я отправлял в письме. И читают регламенты исключительно из-под палки. Хотя, казалось бы, что там: 5 листов, 30 минут осознанного времени, не более. Почему так?
Когда я был маленький, меня заставляли мыть руки перед едой и я всегда бесился: мне это было незачем, это крало мое время и вообще, не слушаться было гораздо веселее, чем слушаться (что будет, если не послушаться маму??)
Когда я подрос, меня заставляли ходить в школу. Там было скучно, ставили странные оценки за неинтересные знания и надо было соблюдать ровно одно правило: не нарушать так, чтобы родителей не вызвали в школу. Потом был институт, где правило было одно: сдай сессию любой ценой. А потом началась работа, где мне стали платить деньги за сделанные проекты, но внезапно переставали платить за несоблюдение каких-то дурацких (как я тогда думал) правил.
«Для документов есть sharepoint, для формирования проекта надо делать бумажку с названием «Устав», который надо у всех подписать руками, для запуска очевидно необходимых работ надо делать документ с вызывающим зевоту названием «Финансово-Экономическое обоснование»».
А я только начал работать: энергии полно, я хочу перевернуть мир. Я точно знаю, чего хочет заказчик, я обсудил все с лидом разработки, работа кипит, через неделю релиз, мы успеваем и тут… Меня вызывает мой руководитель и ругается: проектный план неактуален, документов по проекту нет, тикетов нет, разработчики делают непойми что. Минус премия. Но за что?? Я же сделал проект? Я же обо всем договорился? Нечестно! «Все, я пойду на hh, буду искать место, где ценят не за бумажки, а за реальные результаты» - думал я. Сейчас я понимаю, насколько это была детская позиция. Но тогда никто не смог внятно объяснить, а зачем все это нужно?
Состояние «Я Художник, Я Так Вижу и плевать мне на ваши правила» я периодически встречаю в нашей айтишной среде до сих пор не только у разработчиков, но и у CEO достаточно крупных компаний. Откуда такое пренебрежение правилами, к теме статьи не относится. Важно зафиксировать, что на правила компании многие склонны класть болт, предпочитая работать без правил.
Зачем нужны правила? Ответ очевиден: для того же, для чего нужны законы в стране. Регламенты вашей компании – те же самые законы в миниатюре. Если их не будет совсем, в вашей компании будет бардак. Если их будет слишком много, ваша компания погрязнет в бюрократии. То есть приходим к моей любимой теме: баланс.
Где же баланс?
Когда компания небольшая, описание процессов необязательно, потому что есть всего несколько человек, которые держат в уме все. Клиентов немного, часть помнишь сам, часть - просто спроси. Договориться с коллегой, как использовать пару разработчиков «на лету» - без проблем.
Потом компания начинает расти и спрашивать надо не одного человека, а нескольких. И кто-то из них обязательно что-то забудет (человек неидеален). А кто-то из них отлично работает с клиентом, зато отвратительно следит за документами и у него бардак с отчетностью. А еще компания растет, приходят новые сотрудники, и их надо обучать. И наконец, все работают удаленно, общаясь через мессенджеры, что автоматически сужает канал коммуникации, увеличивая риски непонимания.
По моему опыту, бардак начинается уже в команде от 5-10 разработчиков. Но владельцы или менеджеры смотрят на это сквозь пальцы: вроде все работает, а то, что менеджер ноет, что надо процесс – так это менеджер рукожоп, управлять не умеет.
Когда команда превышает 20-30 человек, отсутствие регламентов становится критичным и начинается бардак. Бизнес не понимает, где обещанные плановые задачи, менеджер тоже не понимает, а Генеральный, понимая, что все сроки нарушаются, по критичным вопросам сам ходит к разработке, что вносит еще бОльший хаос. Начинаются круги операционного треша, который рождает еще больше треша. И на выходе получаем то, что на картинке.
Вот тут появляются регламенты - законы компании. Они нужны, чтобы компания могла расти и развиваться, не утопая в операционном бардаке.
Какие регламенты нужны?
Важно помнить о балансе: правила должны быть, но они не должны существенно тормозить работы. Для небольших команд разработки в 5-20 человек достаточно формализовать следующие шаги:
Поступление новой задачи/проекта: единая точка входа для новых задач, оценка задач, приоритизация задач.
Планирование задачи/проекта: планирование сроков и ресурсов, их фиксация.
Выполнение задачи/проекта: это ваш процесс разработки. Он так или иначе есть у всех, но важно следить за его исполнением согласно п2 выше и ограничивать внеплановые задачи.
Передача в поддержку: проверка достаточности документации, корректности оформления кода и так далее. Все что поможет поддерживать доработки.
Разумеется, регламентов может быть и больше, я говорю о необходимом минимуме, который дальше по мере роста можно масштабировать (к примеру, п1 можно разбить на правила оформления ФТ для бизнеса, правила оценки фич и правила приоритизации беклога и так далее). Главное помнить, что правила должны позволять работать команде с наименьшим количеством конфликтов, выдавая результат в предсказуемые сроки, предоставляя прозрачную отчетность.
Разумеется, из любых правил бывают исключения. Тот же Адзизес, гуру бизнес-консалтинга, говорит, что регламенты могут ограничивать бурный рост компании, когда надо захватывать новые рынки. Но это должны быть именно исключения. А если у вас 50% задач иду вне планов работ, сроки едут и бизнес ругается – наверное, регламенты все-таки нужны ?
Я не буду далее в этой статье расписывать детально все возможные ветвления процесса разработки и какими регламентами он должен покрываться в зависимости от размера отдела разработки - это материал для отдельного цикла или даже тренинга. Задача этой статьи просто дать понимание начинающим и не очень менеджерам того, зачем существуют регламенты и как с ними жить.
Итого:
Менеджерам, которые снисходительно относятся к регламентам, рекомендую помнить, что, не читая регламенты вашей компании, вы:
Саботируете работу вашей компании. Потому что эти правила до вас кто-то придумал и согласовал. И, даже если сейчас вам кажется это глупым, они существуют. Как минимум они стоят того, чтобы их прочитать и, если есть вопросы, их задать.
Подставляете сами себя. Потому что не знание закона не освобождает от ответственности, даже если в остальном вы красавчик и все сдаете в срок.
Ведете себя по-детски и непрофессионально. Убегают от законов дети. Позиция взрослого человека и профессионала - смотреть, работают правила или нет, и, если нет, менять их.
Поэтому читайте регламенты, уважайте их и помните, что они не идеальны. Возможно, вы сможете что-то изменить, чем упростите жизнь себе, вашей команде, начальству, а заодно заработаете себе медальку, плюс классный опыт изменения мира.
На прощание небольшой тест на зрелость вашу и вашей компании (писать результаты можно прямо в моем ТГ канале по ссылке вначале, а можно на Хабре):
Уровень 1: есть ли регламенты управления разработкой в вашей компании?
Уровень 2: читали ли вы их?
Уровень 3: пробовали ли вы их менять?
Уровень 4: меняли ли вы их (п.3 и 4 – это не одно и тоже!)
Если есть все четыре – поздравляю, вы круты, вы способны менять мир вокруг себя. Если нет – вот вам шаги, как сделать вашу компанию чуть лучше и вырасти на этом самим.
Как говорится: «Тихо, тихо ползи, улитка, по склону Фудзи вверх, до самых высот!»
Комментарии (14)
wolodik
04.09.2024 06:23+1Проблема не в том что регламенты читать не хотят, а что любая уважающая себя компания плодит их быстрее чем успеваешь их читать :).
Вывод в "итого" абсолютно верный, хочу только отметить что когда регламенты читают исключительно для того, чтобы не подставляться, это очень хорошо характеризует эти самые регламенты. Значительная часть их написана не для организации работы, а для избегания ответственности, как табличка "купаться запрещено" - всем всё равно можно в этом месте на самом деле купаться или нет, а смысл её чтобы если я утону за это никто не отвечал.
peterzh Автор
04.09.2024 06:23знаете, не всегда, по моему опыту. Может, мне везло, я только один раз работал в компании, где был формализованный бизнес-процесс по заведению других бизнес-процессов и прочая ересь. Такое бывает, когда набирают отдельного человека на роль нормотворца и его KPI выражается в объеме бумаги :)
Где то при переходе от нескольких сотен до тысяч такое может случаться, да. Но это не отменяет того, что они есть и за них может прилететь.
wolodik
04.09.2024 06:23Здесь есть несколько моментов.
Да, знать регламенты необходимо, потому что это помогает защитить себя. Без вариантов.
Нормативка на самом деле очень правильная вещь - я долгое время шарахался при слове ГОСТ, но погрузившись в тему понял насколько стандартизация полезная штука. В том числе когда компания создаёт внутренние "ГОСТы".
Беда начинается, когда к делу подходят комплексно и решают регламентировать всё что видят - тогда вместо регламентов помогающих работать появляются бесконечные тексты про то как надо содержать рабочее место, общаться с коллегами, проводить совещания, оформлять переписку... И главное само по себе оно может и неплохо - но как лавина погребает под собой всё разумное.
Как раз вчера обсуждал эту тему и набросал небольшую заметку по мотивам, может какие мысли будут интересны.wolodik
04.09.2024 06:23Казалось бы какой прекрасный мир, в котором все действия регламентированы. Т.е. разработаны алгоритмы буквально на всё. Включая обработку нештатных ситуаций. Но так не бывает, это иллюзия, разбивающаяся о реальность. Нарисовать всеобъемлющую инструкцию возможно только для полностью детерминированного мира. А в любом реальном есть взаимодействие с непредсказуемыми факторами. Можно конечно попробовать учесть их все, но как показывает практика оно либо не получается, либо инструкция распухает настолько что ей невозможно пользоваться. Но всё бы ничего, если это было бы единственной проблемой!
Номер два - ресурсы. Они всегда ограничены, поэтому их на всех не хватает. Ты можешь сколько угодно писать что должно быть сделано то-то и то-то, но когда у тебя некому или нечем это сделать.. А если это можно не делать или чем-то заменить, возникает вопрос - а правильно ли спроектирован процесс?
И переходим к самому интересному. Правила сами не соблюдаются. За ними нужно следить. И к тому же наказывать тех кто их не соблюдает. Чем больше правил - тем сложнее в них разбираться, тем больше контролёров нужно. Задача контролёра - не сделать хорошо, а сделать по инструкции. Это не из вредности, это by design. Поэтому начинает расти ком проблем - власть в карающем органе опьяняет, подловить на несоблюдении какой-либо инструкции можно любого. И неважно, есть тут злой умысел при административной борьбе, просто вредненький человек, или искренне хочет выполнять свою работу. Инструкции после определённого момента, по мере увеличения их количества, начинают не помогать, а вредить процессам, а увеличиваются они потому что толпа контролёров плодит и совершенствует инструкции до бесконечности, даже если сами понимают что некуда - ибо этим они поддерживают видимость своей работы и пользы.
И в результате благая идея заменяет полезную работу на соблюдение инструкций. Производительность падает, люди увольняются - те кто работать не хочет принимают правила игры и начинают использовать инструкции для обоснования ничегонеделанья, а кто хочет получают постоянные выговоры за их несоблюдение.
Но идёт это постепенно - поэтому это сложно заметить, долгое время руководство радуется как у нас всё гладенько и ровненько, пока не приводит к полной финансовой несостоятельности. Поздний СССР - все строго соблюдают миллион правил, поэтому стройки идут уже не годами, а десятилетиями, но зато всё по инструкции."Внедрение регламентов и инструкций сначала однозначно увеличивает эффективность работы, потом эффект становится разнонаправленным, но после какого-то момента начинается обратный процесс снижения эффективности, вплоть до драматичного."
Elpi
04.09.2024 06:23Сразу видно, что вы в теме, все по делу.
Вы с какой целью в 1001 раз повторили давно известное (но не выполняемое)? Задачу вы себе по этой статье какую ставили?
peterzh Автор
04.09.2024 06:23Задачу ставил простую: я сам был менеджером, который плевал на регламенты, и я вижу вокруг много таких же менеджеров. Цель статьи - обратить их внимание на эту надоедливую и скучную вещь и дать понимание, что это тоже инструмент работы.
Batalmv
04.09.2024 06:23Честно говоря, крайне поверхностно. На этот список без слез не взглянешь
Уровень 1: есть ли регламенты управления разработкой в вашей компании?
Уровень 2: читали ли вы их?
Уровень 3: пробовали ли вы их менять?
Уровень 4: меняли ли вы их (п.3 и 4 – это не одно и тоже!)
Такое ощущение, что компания автора просто находится на уровне развития, когда регламенты появились и теперь наступил конфетно-цветичный период :)
peterzh Автор
04.09.2024 06:23Поверхностно? Я не знаю. Я сам понял, что можно менять регламенты только спустя лет 10 активной работы. До этого я их просто избегал. Если бы я понял это раньше, я считаю, моя работа была бы эффективнее. Отдельно - очень хорошо видно отношение руководства к сотрудникам, когда хочешь что-то изменить, умение вести диалог и так далее.
Я считаю, это очень простой и суперэффективный инструмент.
Batalmv
04.09.2024 06:23Ну, даже не знаю. Ну смотрите. Вы руководитель разработки (наверное). Как минимум стоит иметь документы, которые регламентируют сам процесс разработки. Есть же 100500 нефункциональных моментов, которые стоит делать единобразно. Это и безопасность, и логи, и обработка exception, и куча всего
Если есть это, следующий шаг - как регламентировать действия "наружу" команды. Т.е. задачи, учет времени и т.д.
Просто ... наверное это актуально для вас, но в целом выглядит, что вы еще в начале большого пути :)
peterzh Автор
04.09.2024 06:23Ну, кстати. Регламенты именно разработки кода (кодревью, оформление кода, документирование фич, процесс тестирования и использование инструментов тестирования) я знаю как раз слабовато: я не техдир, я менеджер. У меня всегда был или Лид или ТД для формулировки этого. Это не значит, что я не могу в это, просто одна неделя на изучение. Но обычно менеджера не пускают в технику. Там ребята сами устанавливают свои правила и, я считаю, это правильно
Что касается остальных регламентов, их может быть миллион, как верно выше написали. Если я начну писать все, что видел и знаю там будет от формализации нужного процесса change management до совершенно избыточного "бизнес-процесса по созданию нового бизнес-процесса" (такое тоже было).
Задача статьи была не грузануть людей примерами - любой пример можно оспорить, потому что регламенты создаются индивидуально под компанию. Задача была выделить и дать то, без чего, наверняка будет попа даже в небольшой компании.
zuekliza
04.09.2024 06:23Тут очень тонкая грань между зарытием в бюрократию и соблюдением определённого набора правил, которым нужно дружно следовать всем.
1.Поступление новой задачи/проекта: единая точка входа для новых задач, оценка задач, приоритизация задач.
2.Планирование задачи/проекта: планирование сроков и ресурсов, их фиксация.
Вот тут, по своему опыту сужу, в целом достаточно внутренней договорённости и когда процессом драйвит 1-2 человека (ПМ и, например, менеджер - в зависимости от орг структуры), делая раз в какой-то период общие звонки, что бы вся команда понимала, что её ждёт и где они сейчас, давали свои комментарии перед стартом работ, а не когда уже все в мыле. Плюс это более гибкая часть работы.
3.Выполнение задачи/проекта: это ваш процесс разработки. Он так или иначе есть у всех, но важно следить за его исполнением согласно п2 выше и ограничивать внеплановые задачи.
4.Передача в поддержку: проверка достаточности документации, корректности оформления кода и так далее. Все что поможет поддерживать доработки.
А вот тут должны быть не просто словесные договорённости, а чётко описанный понятный процесс, с которым знакома вся команда и которая должна доходить до автоматизма.
Корректно оформленные задачи уменьшают шансы на некорректную реализацию и тестирование. Наличие документации уменьшает время на проработку требований. Конечно, никто не отменяет умения читать код, но не редко бывает так, что требования нужно изучить чуть менее технически подкованному специалисту, и это опять трата времени.
А когда команда работает сразу над несколькими проектами, то порой уже не всегда вспомнишь, что там было 2 недели назад.
Для новеньких, которые хоть и не часто (у нас почти нет текучки) я всегда говорю - описывает максимально подробно те же требования / репро шаги / тестовые сценарии так, что бы человек, не сведующий в данной теме мог понять о чем речь и куда смотреть. Да даже банально для будущих потомков всего этого наследия.
Aleh-Kash
Такое ощущение, что в конце статьи что-то поломалось. Например:
"Если есть все четыре – поздравляю, вы круты, вы способны менять мир вокруг себя. Если нет – вот вам шаги, как сделать вашу компанию чуть лучше и вырасти на этом самим".
Шагов нет, есть только рисунок с улиткой. Где шаги?
Где эти регламенты?
Без конкретики это просто статья-лозунг: "Хорошо работать - это хорошо, а плохо работать - это плохо". Не нужно брать пример с т.н. "коучей".
peterzh Автор
в конце и правда поломалось, ошибка копипасты. Исправлено, спасибо.
Регламенты есть выше , раздел "Какие регламенты нужны" - там есть 4 базовых, которые нужны всегда. И там же сказано, что детально расписать эти регламенты - это отдельный цикл статей.
Цель этой статьи - не дать свод регламентов, а внушить менеджерам-раздолбаям (а их много) понимание, что регламенты - это: а) важно, б) полезно.
Шаги есть , может, неясно написано, действительно:
aimfirst
Я бы разделил п.4 на 2: менять регламенты и менять их к лучшему - это два разных уровня. В одной компании поменяли регламенты сопровождения, после чего продолжительность обслуживания инцидентов возросла в 6-8 раз...