Comments 14
Такое ощущение, что в конце статьи что-то поломалось. Например:
"Если есть все четыре – поздравляю, вы круты, вы способны менять мир вокруг себя. Если нет – вот вам шаги, как сделать вашу компанию чуть лучше и вырасти на этом самим".
Шагов нет, есть только рисунок с улиткой. Где шаги?
Вот регламенты, которые стоит делать в любом случае любой ИТ команде, это подходит и для внутреннего ИТ, поддерживающего и развивающего инфраструктуру своей компании и продуктовых компаний (сильно похоже на предыдущий пункт) и для интеграторов.
Где эти регламенты?
Без конкретики это просто статья-лозунг: "Хорошо работать - это хорошо, а плохо работать - это плохо". Не нужно брать пример с т.н. "коучей".
в конце и правда поломалось, ошибка копипасты. Исправлено, спасибо.
Регламенты есть выше , раздел "Какие регламенты нужны" - там есть 4 базовых, которые нужны всегда. И там же сказано, что детально расписать эти регламенты - это отдельный цикл статей.
Цель этой статьи - не дать свод регламентов, а внушить менеджерам-раздолбаям (а их много) понимание, что регламенты - это: а) важно, б) полезно.
Шаги есть , может, неясно написано, действительно:
Проблема не в том что регламенты читать не хотят, а что любая уважающая себя компания плодит их быстрее чем успеваешь их читать :).
Вывод в "итого" абсолютно верный, хочу только отметить что когда регламенты читают исключительно для того, чтобы не подставляться, это очень хорошо характеризует эти самые регламенты. Значительная часть их написана не для организации работы, а для избегания ответственности, как табличка "купаться запрещено" - всем всё равно можно в этом месте на самом деле купаться или нет, а смысл её чтобы если я утону за это никто не отвечал.
знаете, не всегда, по моему опыту. Может, мне везло, я только один раз работал в компании, где был формализованный бизнес-процесс по заведению других бизнес-процессов и прочая ересь. Такое бывает, когда набирают отдельного человека на роль нормотворца и его KPI выражается в объеме бумаги :)
Где то при переходе от нескольких сотен до тысяч такое может случаться, да. Но это не отменяет того, что они есть и за них может прилететь.
Здесь есть несколько моментов.
Да, знать регламенты необходимо, потому что это помогает защитить себя. Без вариантов.
Нормативка на самом деле очень правильная вещь - я долгое время шарахался при слове ГОСТ, но погрузившись в тему понял насколько стандартизация полезная штука. В том числе когда компания создаёт внутренние "ГОСТы".
Беда начинается, когда к делу подходят комплексно и решают регламентировать всё что видят - тогда вместо регламентов помогающих работать появляются бесконечные тексты про то как надо содержать рабочее место, общаться с коллегами, проводить совещания, оформлять переписку... И главное само по себе оно может и неплохо - но как лавина погребает под собой всё разумное.
Как раз вчера обсуждал эту тему и набросал небольшую заметку по мотивам, может какие мысли будут интересны.
Казалось бы какой прекрасный мир, в котором все действия регламентированы. Т.е. разработаны алгоритмы буквально на всё. Включая обработку нештатных ситуаций. Но так не бывает, это иллюзия, разбивающаяся о реальность. Нарисовать всеобъемлющую инструкцию возможно только для полностью детерминированного мира. А в любом реальном есть взаимодействие с непредсказуемыми факторами. Можно конечно попробовать учесть их все, но как показывает практика оно либо не получается, либо инструкция распухает настолько что ей невозможно пользоваться. Но всё бы ничего, если это было бы единственной проблемой!
Номер два - ресурсы. Они всегда ограничены, поэтому их на всех не хватает. Ты можешь сколько угодно писать что должно быть сделано то-то и то-то, но когда у тебя некому или нечем это сделать.. А если это можно не делать или чем-то заменить, возникает вопрос - а правильно ли спроектирован процесс?
И переходим к самому интересному. Правила сами не соблюдаются. За ними нужно следить. И к тому же наказывать тех кто их не соблюдает. Чем больше правил - тем сложнее в них разбираться, тем больше контролёров нужно. Задача контролёра - не сделать хорошо, а сделать по инструкции. Это не из вредности, это by design. Поэтому начинает расти ком проблем - власть в карающем органе опьяняет, подловить на несоблюдении какой-либо инструкции можно любого. И неважно, есть тут злой умысел при административной борьбе, просто вредненький человек, или искренне хочет выполнять свою работу. Инструкции после определённого момента, по мере увеличения их количества, начинают не помогать, а вредить процессам, а увеличиваются они потому что толпа контролёров плодит и совершенствует инструкции до бесконечности, даже если сами понимают что некуда - ибо этим они поддерживают видимость своей работы и пользы.
И в результате благая идея заменяет полезную работу на соблюдение инструкций. Производительность падает, люди увольняются - те кто работать не хочет принимают правила игры и начинают использовать инструкции для обоснования ничегонеделанья, а кто хочет получают постоянные выговоры за их несоблюдение.
Но идёт это постепенно - поэтому это сложно заметить, долгое время руководство радуется как у нас всё гладенько и ровненько, пока не приводит к полной финансовой несостоятельности. Поздний СССР - все строго соблюдают миллион правил, поэтому стройки идут уже не годами, а десятилетиями, но зато всё по инструкции.
"Внедрение регламентов и инструкций сначала однозначно увеличивает эффективность работы, потом эффект становится разнонаправленным, но после какого-то момента начинается обратный процесс снижения эффективности, вплоть до драматичного."
Сразу видно, что вы в теме, все по делу.
Вы с какой целью в 1001 раз повторили давно известное (но не выполняемое)? Задачу вы себе по этой статье какую ставили?
Честно говоря, крайне поверхностно. На этот список без слез не взглянешь
Уровень 1: есть ли регламенты управления разработкой в вашей компании?
Уровень 2: читали ли вы их?
Уровень 3: пробовали ли вы их менять?
Уровень 4: меняли ли вы их (п.3 и 4 – это не одно и тоже!)
Такое ощущение, что компания автора просто находится на уровне развития, когда регламенты появились и теперь наступил конфетно-цветичный период :)
Поверхностно? Я не знаю. Я сам понял, что можно менять регламенты только спустя лет 10 активной работы. До этого я их просто избегал. Если бы я понял это раньше, я считаю, моя работа была бы эффективнее. Отдельно - очень хорошо видно отношение руководства к сотрудникам, когда хочешь что-то изменить, умение вести диалог и так далее.
Я считаю, это очень простой и суперэффективный инструмент.
Ну, даже не знаю. Ну смотрите. Вы руководитель разработки (наверное). Как минимум стоит иметь документы, которые регламентируют сам процесс разработки. Есть же 100500 нефункциональных моментов, которые стоит делать единобразно. Это и безопасность, и логи, и обработка exception, и куча всего
Если есть это, следующий шаг - как регламентировать действия "наружу" команды. Т.е. задачи, учет времени и т.д.
Просто ... наверное это актуально для вас, но в целом выглядит, что вы еще в начале большого пути :)
Ну, кстати. Регламенты именно разработки кода (кодревью, оформление кода, документирование фич, процесс тестирования и использование инструментов тестирования) я знаю как раз слабовато: я не техдир, я менеджер. У меня всегда был или Лид или ТД для формулировки этого. Это не значит, что я не могу в это, просто одна неделя на изучение. Но обычно менеджера не пускают в технику. Там ребята сами устанавливают свои правила и, я считаю, это правильно
Что касается остальных регламентов, их может быть миллион, как верно выше написали. Если я начну писать все, что видел и знаю там будет от формализации нужного процесса change management до совершенно избыточного "бизнес-процесса по созданию нового бизнес-процесса" (такое тоже было).
Задача статьи была не грузануть людей примерами - любой пример можно оспорить, потому что регламенты создаются индивидуально под компанию. Задача была выделить и дать то, без чего, наверняка будет попа даже в небольшой компании.
Тут очень тонкая грань между зарытием в бюрократию и соблюдением определённого набора правил, которым нужно дружно следовать всем.
1.Поступление новой задачи/проекта: единая точка входа для новых задач, оценка задач, приоритизация задач.
2.Планирование задачи/проекта: планирование сроков и ресурсов, их фиксация.
Вот тут, по своему опыту сужу, в целом достаточно внутренней договорённости и когда процессом драйвит 1-2 человека (ПМ и, например, менеджер - в зависимости от орг структуры), делая раз в какой-то период общие звонки, что бы вся команда понимала, что её ждёт и где они сейчас, давали свои комментарии перед стартом работ, а не когда уже все в мыле. Плюс это более гибкая часть работы.
3.Выполнение задачи/проекта: это ваш процесс разработки. Он так или иначе есть у всех, но важно следить за его исполнением согласно п2 выше и ограничивать внеплановые задачи.
4.Передача в поддержку: проверка достаточности документации, корректности оформления кода и так далее. Все что поможет поддерживать доработки.
А вот тут должны быть не просто словесные договорённости, а чётко описанный понятный процесс, с которым знакома вся команда и которая должна доходить до автоматизма.
Корректно оформленные задачи уменьшают шансы на некорректную реализацию и тестирование. Наличие документации уменьшает время на проработку требований. Конечно, никто не отменяет умения читать код, но не редко бывает так, что требования нужно изучить чуть менее технически подкованному специалисту, и это опять трата времени.
А когда команда работает сразу над несколькими проектами, то порой уже не всегда вспомнишь, что там было 2 недели назад.
Для новеньких, которые хоть и не часто (у нас почти нет текучки) я всегда говорю - описывает максимально подробно те же требования / репро шаги / тестовые сценарии так, что бы человек, не сведующий в данной теме мог понять о чем речь и куда смотреть. Да даже банально для будущих потомков всего этого наследия.
О пользе регламентов в жизни руководителя ИТ разработки