Для меня эта история больше не про то, что вы использовали подход OMG Essense, а просто оцифровали работу с проектами в компании по всем кубикам, начиная от ее оценки и финанисрования до контроля исполнения.
Однако самый любопытный вопрос остался за кадром: дашборд все показывает красиво, когда он хорошо настроен на необходимые учетные системы.
Откуда берется информация о:
процессе бюджетирования - интегрировано с какой то внутренней системой или ведется вручную?
контроля бейзлайнов и текущих работ (Гантт) - интегрировано с внешней системой или является частью вашего продукта?
контроля рисков - берется из внешней системы или ведется в этом продукте? кто заполняет риски и кто определяет их вес для системы?
вы помянули коннектор к JIRA для получения данных по задачам, а для чего вам эти данные и как вы связываете план и факт в системе?
У проджектов СберМаркета есть руководители в доменах. Чаще всего это технические менеджеры. Они дают сроки выполнения проекта, определяют оптимальную стоимость с точки зрения ресурсов.
Любопытно, обычно у менеджеров руководитель - это РПО. почему у вас РП подчиняются тех лидам? И где эти тех лиды в структуре домена? Это лиды команды, лиды юнита или тех лид (фактически тех дир) домена?
Lead Time. Медианное время выполнения проектов во всех кросс-функциональных командах — с момента начала Discovery до раскатки на всех клиентов.
мне интересно, как вы сравниваете несравнимое, ведь каждый проект уникален и по срокам и по ресурсам? или вы исходите из допущения, что проекты у вас в среднем по каждому году - стандартные?
и, кстати, это еще и функция аккуратности ведения проектов в учетной системе. Велась ли она также аккуратно ДО введения проектного офиса, как после него?
Про дорожные карты и ресурсное планирование. Вы упомянули использование JIRA STRUCTURE для планирования. Но этот плагин не умеет планировать задачи и ресурсы без тикетов в JIRA, насколько мне известно. Значит ли это, что на каждую планируемую задачу в роадмапе у вас заводится тикет с эстимейтом, который ставится на сотрудников?
подвопрос: а что потом происходит с такой задачей, вы ее удаляете и заменяете на реальную декомпозицию по этой задаче?
В функциях деливери менеджера мне видится роль методолога проектного офиса. Роль, которая смотрит узкие места в процессах выполнения проектов и устраняет их, внедряя best practices. Или это что-то другое?
для меня, как менеджера с 20 летним опытом управления проектами и 7и летнем опыте выстраивания ИТ производств было удивительно узнать что ребята из СОВНЕТ аж ГОСТ сделали по проектному офису. Хоть почитаю, что там :)
Я работаю в основном на стороне системный интеграторов ИТ и у нас, как я понимаю, обычно такая методология:
В проектной компании типовые проекты реализуются обычно как регулярный процесс.
Собственно я , как РПО описывал все эти регулярные процессы инициации, ведения и завершения.
С уважением отношусь к труду автора и огромному количеству проработанного материала. И хочу сказать, что структурирование chat gpt в конце для меня гораздо более стройное, нежели в самой статье. Ощущение, что сказано +- тоже самое, но в разы короче и структурированнее. Отсюда делаю вывод, что статью стоило бы переработать не по содержанию, но по структуре. В целом все равно интересно, пойду читать часть 2, спасибо
По моему опыту именно тогда и всплывают типовые риски в статье выше, как ответы на вопрос "Почему так дорого и долго?".
Потому что здесь не определен функционал, потому что здесь у вас нет требований к интеграции, а она будет, потому что мы заменяем старую учетную систему и данные надо будет перенести.... ну и так далее.
Любая бюрократия (а реестр рисков - это документ, требующий обновления и поддержания) должна быть оправдана, чтобы не перегружать РП избыточной работой.
Цель этой статьи (да и остальных моих тоже) - как раз найти этот баланс.
Делать реестр рисков для проектов уровня "создать веб сайт" будет как то странно, я думаю, вы не будете тут спорить. А таких проектов ведь очень много и РП там искренне не понимают, зачем им пихают Risk management и когда он нужен...
Верно, это простейший эксель. Я не вижу ни одной причины усложнять этот процесс. У меня были проекты с командами до 100 человек и этой простой таблички мне всегда хватало.
Разумеется есть сложнейшие методологии расчета рисков, они описаны здесь же, на Хабре. Я искренне не понимаю, зачем их использовать на 95% ИТ проектов, где моей таблички будет более, чем достаточно. Статья как раз про это.
а позвольте полюбопытствовать про перенос продуктов и заявок: какое количество продуктов было перенесено и какое количество заявок по продуктам было перенесено? Просто порядок: десятки, сотни, тысячи, сотни тысяч?
переносилась ли история по заявкам из старой системы в новую?
интегрирована ли указанная система с какими либо другими или она standalone?
я ITSM давно не выбирал, хотя лет 7 назад руководил ITIL/ITSM направлением в одном интеграторе. Решил немного вмешаться: все ITSM решения более менее похожи друг на друга, и почти все (кроме тех, что изобретают велосипед) базируются на модели услуг ITIL. Здесь, кажется, таже самая история: продукт = услуга, система = КЕ.
Я бы сейчас при выборе ITSM в первую очередь смотрел на косты доработок (допилить новый процесс под новый продукт + стоимость интеграции (к примеру, если я захочу интегрировать ее и мониторинг для автоматического заведения инцидентов. Вот тут могут начаться приключения, особенно с облачными продуктами. С точки зрения "дать красивую картинку, особенно в сравнении с откровенно устаревшим Редмайном - они сгодятся все :)
И прочитал вашу статью для Ланита по организации процесса разработки.
Все так, это кубик "Исполнение" (в прошлом комментарии также "исполнение", ошибся). Как я и написал в статье:
Тут должны быть правила разработки по этапам (дизайн-разработка-тестирование), включая правила постановки задачи в вашем инструменте (трекер, как правило), правила оформления кода, правила работы с репозиториями, правила списания времени, правила внутреннего тестирования
Еще раз поясню идею: для большого проекта (например, который описываете вы), этапами по моему процессу будут следующие шаги (смотрим со стороны Заказчика):
формирование требований - происходит внутри заказчика. Компания интегратор вообще этого может не знать (ну и по ФЗ не должна знать, даже если бывает иначе)
предварительная оценка - тоже самое
согласование бюджета - аналогично
планирование - исполнителя еще нет, работы выполняются внутри Заказчика
исполнение - вот тут появляется ГК, играется конкурс и появляется компания-интегратор, тот же Ланит. Который выполняет работы, сдает и передает в эксплуатацию
А если поглядеть на работу самого Ланита, как интегратора, будет так
Пресейл
поступление требования. Ланитовский продавец приходит в Проектный офис Ланита и предупреждает, что у него планируется проект. Он не должен приходить мимо ПМО к разработчикам и аналитикам - тогда будет хаос, описанный в статье.
примерная оценка необходимого бюджета на пресейл: проводится совместно с выделенным менеджером проектного офиса Ланит.
согласование оценки и выделение ресурсов на пресейл, фиксация сроков.
Реализация
Планирование - менеджер, выделенный проектным офисом делает план и подписывается под сроки и бюджет
Неа, присутствует. Это кубик "Разработка". Я прочитал вашу статью. В вашем примере это будет Разработка->Аналитика:
регламент сбора требований
регламент согласования требований
регламент постановки задач на разработку
регламент оформления выходной документации
помимо этого я уверен, будет так же много требований к разработке (как правило на таких проектах несколько команд разработки), внутреннему тестированию, ну и ПМИ (причем, не одна). И
то как раз отличный пример масштабирования моих кубиков.
К примеру, для обновления интеграции вебсайта и мобильного приложения для работы с системой Мир-Пей такого подхода будет не нужно. А таких задач в ИТ отделе крупных компаний намного больше.
Моя задача была - взглянуть на процесс работы вообще любой команды "сверху". Для начала надо так, а потом опускаться ниже, включая определение сбора требований и согласования техрешений.
Нет, это не ошибка, а вполне успешный опыт моей работы и консалтинга для наших заказчиков. Я достаточно много общался с Техдирами и CIO разных компаний, я понимаю их аргументы и мне есть, что ответить.
Когда я читаю про "колесо сансары"... Я всю жизнь автоматизирую процессы. Я строил процессы гораздо сложнее того, что описан выше. И у меня вопрос: почему для бизнеса мы все можем формализовать, а ИТ процесс - это неформализуемое колесо сансары, где команда выгорает?
А не проблема ли это руководителя такой команды?
Так что буду очень раз, если вы дадите пару реальных кейсов, где указанная модель не работала.
Мне сдается, что у мы с вами , действительно, про разное говорим. Все верно, научно исследовательскими задачами я не занимался и никогда не руководил. Да, автоматизировал процессы, да, крупные тоже автоматизировал, но вот прямо новое - новое нет. И для нового я бы сам пробовал принципы agile манифеста: попилили - поглядели. Попилили еще. И так далее.
Ну или есть большие НИОКРы, где так не получится и надо вбухивать деньги в надежде что когда-то получится.
Такого опыта нет.
Я работал много где и я вижу, что бОльшая часть рынка - это типовые Энтерпрайз задачи по оптимизации существующих процессов. И вот в этом месте мои кубики отлично будут работать. Все компании, с которыми я сталкивался, так или иначе решали вопросы по этим кубикам.
В случае, описанном вами выше, проблемах на Приемке, это отлично описывается документом ПМИ, который основан на ЧТЗ, которое заказчик согласовал. Там есть нюансы, но всегда там можно договориться, если у менеджера проектов есть воля (ну и на фазе анализа ничего глобального не проворонили).
По новому разработчику - о да, на такое заложиться вполне можно. Я уже статистически вижу риски и закладываю их в план. Это опыт. конечно.
И осечки бывают, но среднее по больнице вполне неплохо прогнозируется :)
В статье даны 7 четких точек контроля процесса любой ИТ команды. Бери и делай.
По вашему примеру с оценкой, я скажу достаточно категорично, просто потому что у меня опыт разных оценок больше 20 лет: если человек раз за разом не попадает в оценку, он джун и ему надо учиться. Это касается и разработчика, и аналитика, и менеджера. Бывают исключения, где чистая научно-исследовательская работа, но стандартная работа ИТ отдела это: допилить интеграцию, добавить раздел на сайт и тп - не ракетные технологии.
Для примера, я давал оценку на проект за 1 млн usd на год вперед и попал в нее с точностью до 0.5% - проверил спустя год, и сам удивился.
Agile вообще не является методологией, давайте будем корректны. Это общее описание гибкой разработки, которая задается только Agile Manifesto. Принципам которого, кстати, противоречит моя статья.
И это очень важно заметить: да, для небольших команд, где продакт и команда сидят вместе то, что есть в Манифесте работает отлично. Как только растет команда - придется отделять и формализовывать все, что я описал выше.
Ну, кстати. Регламенты именно разработки кода (кодревью, оформление кода, документирование фич, процесс тестирования и использование инструментов тестирования) я знаю как раз слабовато: я не техдир, я менеджер. У меня всегда был или Лид или ТД для формулировки этого. Это не значит, что я не могу в это, просто одна неделя на изучение. Но обычно менеджера не пускают в технику. Там ребята сами устанавливают свои правила и, я считаю, это правильно
Что касается остальных регламентов, их может быть миллион, как верно выше написали. Если я начну писать все, что видел и знаю там будет от формализации нужного процесса change management до совершенно избыточного "бизнес-процесса по созданию нового бизнес-процесса" (такое тоже было).
Задача статьи была не грузануть людей примерами - любой пример можно оспорить, потому что регламенты создаются индивидуально под компанию. Задача была выделить и дать то, без чего, наверняка будет попа даже в небольшой компании.
Поверхностно? Я не знаю. Я сам понял, что можно менять регламенты только спустя лет 10 активной работы. До этого я их просто избегал. Если бы я понял это раньше, я считаю, моя работа была бы эффективнее. Отдельно - очень хорошо видно отношение руководства к сотрудникам, когда хочешь что-то изменить, умение вести диалог и так далее.
Я считаю, это очень простой и суперэффективный инструмент.
Задачу ставил простую: я сам был менеджером, который плевал на регламенты, и я вижу вокруг много таких же менеджеров. Цель статьи - обратить их внимание на эту надоедливую и скучную вещь и дать понимание, что это тоже инструмент работы.
знаете, не всегда, по моему опыту. Может, мне везло, я только один раз работал в компании, где был формализованный бизнес-процесс по заведению других бизнес-процессов и прочая ересь. Такое бывает, когда набирают отдельного человека на роль нормотворца и его KPI выражается в объеме бумаги :)
Где то при переходе от нескольких сотен до тысяч такое может случаться, да. Но это не отменяет того, что они есть и за них может прилететь.
в конце и правда поломалось, ошибка копипасты. Исправлено, спасибо.
Регламенты есть выше , раздел "Какие регламенты нужны" - там есть 4 базовых, которые нужны всегда. И там же сказано, что детально расписать эти регламенты - это отдельный цикл статей.
Цель этой статьи - не дать свод регламентов, а внушить менеджерам-раздолбаям (а их много) понимание, что регламенты - это: а) важно, б) полезно.
Шаги есть , может, неясно написано, действительно:
Спасибо за опыт.
Для меня эта история больше не про то, что вы использовали подход OMG Essense, а просто оцифровали работу с проектами в компании по всем кубикам, начиная от ее оценки и финанисрования до контроля исполнения.
Однако самый любопытный вопрос остался за кадром: дашборд все показывает красиво, когда он хорошо настроен на необходимые учетные системы.
Откуда берется информация о:
процессе бюджетирования - интегрировано с какой то внутренней системой или ведется вручную?
контроля бейзлайнов и текущих работ (Гантт) - интегрировано с внешней системой или является частью вашего продукта?
контроля рисков - берется из внешней системы или ведется в этом продукте? кто заполняет риски и кто определяет их вес для системы?
вы помянули коннектор к JIRA для получения данных по задачам, а для чего вам эти данные и как вы связываете план и факт в системе?
Спасибо за опыт , прочитал с большим интересом.
Возникло немного вопросов (4)
Вдруг ответите
Любопытно, обычно у менеджеров руководитель - это РПО. почему у вас РП подчиняются тех лидам? И где эти тех лиды в структуре домена? Это лиды команды, лиды юнита или тех лид (фактически тех дир) домена?
мне интересно, как вы сравниваете несравнимое, ведь каждый проект уникален и по срокам и по ресурсам? или вы исходите из допущения, что проекты у вас в среднем по каждому году - стандартные?
и, кстати, это еще и функция аккуратности ведения проектов в учетной системе. Велась ли она также аккуратно ДО введения проектного офиса, как после него?
Про дорожные карты и ресурсное планирование.
Вы упомянули использование JIRA STRUCTURE для планирования. Но этот плагин не умеет планировать задачи и ресурсы без тикетов в JIRA, насколько мне известно. Значит ли это, что на каждую планируемую задачу в роадмапе у вас заводится тикет с эстимейтом, который ставится на сотрудников?
подвопрос: а что потом происходит с такой задачей, вы ее удаляете и заменяете на реальную декомпозицию по этой задаче?
В функциях деливери менеджера мне видится роль методолога проектного офиса. Роль, которая смотрит узкие места в процессах выполнения проектов и устраняет их, внедряя best practices. Или это что-то другое?
спасибо если прочитаете и скажете че нибудь)
спасибо за статью.
для меня, как менеджера с 20 летним опытом управления проектами и 7и летнем опыте выстраивания ИТ производств было удивительно узнать что ребята из СОВНЕТ аж ГОСТ сделали по проектному офису. Хоть почитаю, что там :)
Я работаю в основном на стороне системный интеграторов ИТ и у нас, как я понимаю, обычно такая методология:
Собственно я , как РПО описывал все эти регулярные процессы инициации, ведения и завершения.
С уважением отношусь к труду автора и огромному количеству проработанного материала. И хочу сказать, что структурирование chat gpt в конце для меня гораздо более стройное, нежели в самой статье. Ощущение, что сказано +- тоже самое, но в разы короче и структурированнее. Отсюда делаю вывод, что статью стоило бы переработать не по содержанию, но по структуре. В целом все равно интересно, пойду читать часть 2, спасибо
Иногда такие суммы и сроки просят обосновать.
По моему опыту именно тогда и всплывают типовые риски в статье выше, как ответы на вопрос "Почему так дорого и долго?".
Потому что здесь не определен функционал, потому что здесь у вас нет требований к интеграции, а она будет, потому что мы заменяем старую учетную систему и данные надо будет перенести.... ну и так далее.
Любая бюрократия (а реестр рисков - это документ, требующий обновления и поддержания) должна быть оправдана, чтобы не перегружать РП избыточной работой.
Цель этой статьи (да и остальных моих тоже) - как раз найти этот баланс.
Делать реестр рисков для проектов уровня "создать веб сайт" будет как то странно, я думаю, вы не будете тут спорить. А таких проектов ведь очень много и РП там искренне не понимают, зачем им пихают Risk management и когда он нужен...
Верно, это простейший эксель. Я не вижу ни одной причины усложнять этот процесс. У меня были проекты с командами до 100 человек и этой простой таблички мне всегда хватало.
Разумеется есть сложнейшие методологии расчета рисков, они описаны здесь же, на Хабре. Я искренне не понимаю, зачем их использовать на 95% ИТ проектов, где моей таблички будет более, чем достаточно. Статья как раз про это.
а позвольте полюбопытствовать про перенос продуктов и заявок: какое количество продуктов было перенесено и какое количество заявок по продуктам было перенесено? Просто порядок: десятки, сотни, тысячи, сотни тысяч?
переносилась ли история по заявкам из старой системы в новую?
интегрирована ли указанная система с какими либо другими или она standalone?
я ITSM давно не выбирал, хотя лет 7 назад руководил ITIL/ITSM направлением в одном интеграторе. Решил немного вмешаться: все ITSM решения более менее похожи друг на друга, и почти все (кроме тех, что изобретают велосипед) базируются на модели услуг ITIL. Здесь, кажется, таже самая история: продукт = услуга, система = КЕ.
Я бы сейчас при выборе ITSM в первую очередь смотрел на косты доработок (допилить новый процесс под новый продукт + стоимость интеграции (к примеру, если я захочу интегрировать ее и мониторинг для автоматического заведения инцидентов. Вот тут могут начаться приключения, особенно с облачными продуктами. С точки зрения "дать красивую картинку, особенно в сравнении с откровенно устаревшим Редмайном - они сгодятся все :)
И прочитал вашу статью для Ланита по организации процесса разработки.
Все так, это кубик "Исполнение" (в прошлом комментарии также "исполнение", ошибся). Как я и написал в статье:
Еще раз поясню идею: для большого проекта (например, который описываете вы), этапами по моему процессу будут следующие шаги (смотрим со стороны Заказчика):
формирование требований - происходит внутри заказчика. Компания интегратор вообще этого может не знать (ну и по ФЗ не должна знать, даже если бывает иначе)
предварительная оценка - тоже самое
согласование бюджета - аналогично
планирование - исполнителя еще нет, работы выполняются внутри Заказчика
исполнение - вот тут появляется ГК, играется конкурс и появляется компания-интегратор, тот же Ланит. Который выполняет работы, сдает и передает в эксплуатацию
А если поглядеть на работу самого Ланита, как интегратора, будет так
Пресейл
поступление требования. Ланитовский продавец приходит в Проектный офис Ланита и предупреждает, что у него планируется проект. Он не должен приходить мимо ПМО к разработчикам и аналитикам - тогда будет хаос, описанный в статье.
примерная оценка необходимого бюджета на пресейл: проводится совместно с выделенным менеджером проектного офиса Ланит.
согласование оценки и выделение ресурсов на пресейл, фиксация сроков.
Реализация
Планирование - менеджер, выделенный проектным офисом делает план и подписывается под сроки и бюджет
исполнение - про это вы написали, добавить нечего
сдача заказчику
передача в эксплуатацию
Все.
Неа, присутствует. Это кубик "Разработка". Я прочитал вашу статью. В вашем примере это будет Разработка->Аналитика:
регламент сбора требований
регламент согласования требований
регламент постановки задач на разработку
регламент оформления выходной документации
помимо этого я уверен, будет так же много требований к разработке (как правило на таких проектах несколько команд разработки), внутреннему тестированию, ну и ПМИ (причем, не одна). И
то как раз отличный пример масштабирования моих кубиков.
К примеру, для обновления интеграции вебсайта и мобильного приложения для работы с системой Мир-Пей такого подхода будет не нужно. А таких задач в ИТ отделе крупных компаний намного больше.
Моя задача была - взглянуть на процесс работы вообще любой команды "сверху". Для начала надо так, а потом опускаться ниже, включая определение сбора требований и согласования техрешений.
Нет, это не ошибка, а вполне успешный опыт моей работы и консалтинга для наших заказчиков. Я достаточно много общался с Техдирами и CIO разных компаний, я понимаю их аргументы и мне есть, что ответить.
Когда я читаю про "колесо сансары"... Я всю жизнь автоматизирую процессы. Я строил процессы гораздо сложнее того, что описан выше. И у меня вопрос: почему для бизнеса мы все можем формализовать, а ИТ процесс - это неформализуемое колесо сансары, где команда выгорает?
А не проблема ли это руководителя такой команды?
Так что буду очень раз, если вы дадите пару реальных кейсов, где указанная модель не работала.
Мне сдается, что у мы с вами , действительно, про разное говорим. Все верно, научно исследовательскими задачами я не занимался и никогда не руководил. Да, автоматизировал процессы, да, крупные тоже автоматизировал, но вот прямо новое - новое нет. И для нового я бы сам пробовал принципы agile манифеста: попилили - поглядели. Попилили еще. И так далее.
Ну или есть большие НИОКРы, где так не получится и надо вбухивать деньги в надежде что когда-то получится.
Такого опыта нет.
Я работал много где и я вижу, что бОльшая часть рынка - это типовые Энтерпрайз задачи по оптимизации существующих процессов. И вот в этом месте мои кубики отлично будут работать. Все компании, с которыми я сталкивался, так или иначе решали вопросы по этим кубикам.
В случае, описанном вами выше, проблемах на Приемке, это отлично описывается документом ПМИ, который основан на ЧТЗ, которое заказчик согласовал. Там есть нюансы, но всегда там можно договориться, если у менеджера проектов есть воля (ну и на фазе анализа ничего глобального не проворонили).
По новому разработчику - о да, на такое заложиться вполне можно. Я уже статистически вижу риски и закладываю их в план. Это опыт. конечно.
И осечки бывают, но среднее по больнице вполне неплохо прогнозируется :)
не соглашусь с вами про "заупокой" :)
В статье даны 7 четких точек контроля процесса любой ИТ команды. Бери и делай.
По вашему примеру с оценкой, я скажу достаточно категорично, просто потому что у меня опыт разных оценок больше 20 лет: если человек раз за разом не попадает в оценку, он джун и ему надо учиться. Это касается и разработчика, и аналитика, и менеджера. Бывают исключения, где чистая научно-исследовательская работа, но стандартная работа ИТ отдела это: допилить интеграцию, добавить раздел на сайт и тп - не ракетные технологии.
Для примера, я давал оценку на проект за 1 млн usd на год вперед и попал в нее с точностью до 0.5% - проверил спустя год, и сам удивился.
Agile вообще не является методологией, давайте будем корректны. Это общее описание гибкой разработки, которая задается только Agile Manifesto. Принципам которого, кстати, противоречит моя статья.
И это очень важно заметить: да, для небольших команд, где продакт и команда сидят вместе то, что есть в Манифесте работает отлично. Как только растет команда - придется отделять и формализовывать все, что я описал выше.
Ну, кстати. Регламенты именно разработки кода (кодревью, оформление кода, документирование фич, процесс тестирования и использование инструментов тестирования) я знаю как раз слабовато: я не техдир, я менеджер. У меня всегда был или Лид или ТД для формулировки этого. Это не значит, что я не могу в это, просто одна неделя на изучение. Но обычно менеджера не пускают в технику. Там ребята сами устанавливают свои правила и, я считаю, это правильно
Что касается остальных регламентов, их может быть миллион, как верно выше написали. Если я начну писать все, что видел и знаю там будет от формализации нужного процесса change management до совершенно избыточного "бизнес-процесса по созданию нового бизнес-процесса" (такое тоже было).
Задача статьи была не грузануть людей примерами - любой пример можно оспорить, потому что регламенты создаются индивидуально под компанию. Задача была выделить и дать то, без чего, наверняка будет попа даже в небольшой компании.
Поверхностно? Я не знаю. Я сам понял, что можно менять регламенты только спустя лет 10 активной работы. До этого я их просто избегал. Если бы я понял это раньше, я считаю, моя работа была бы эффективнее. Отдельно - очень хорошо видно отношение руководства к сотрудникам, когда хочешь что-то изменить, умение вести диалог и так далее.
Я считаю, это очень простой и суперэффективный инструмент.
Задачу ставил простую: я сам был менеджером, который плевал на регламенты, и я вижу вокруг много таких же менеджеров. Цель статьи - обратить их внимание на эту надоедливую и скучную вещь и дать понимание, что это тоже инструмент работы.
знаете, не всегда, по моему опыту. Может, мне везло, я только один раз работал в компании, где был формализованный бизнес-процесс по заведению других бизнес-процессов и прочая ересь. Такое бывает, когда набирают отдельного человека на роль нормотворца и его KPI выражается в объеме бумаги :)
Где то при переходе от нескольких сотен до тысяч такое может случаться, да. Но это не отменяет того, что они есть и за них может прилететь.
в конце и правда поломалось, ошибка копипасты. Исправлено, спасибо.
Регламенты есть выше , раздел "Какие регламенты нужны" - там есть 4 базовых, которые нужны всегда. И там же сказано, что детально расписать эти регламенты - это отдельный цикл статей.
Цель этой статьи - не дать свод регламентов, а внушить менеджерам-раздолбаям (а их много) понимание, что регламенты - это: а) важно, б) полезно.
Шаги есть , может, неясно написано, действительно:
Влада, просто вам совет, вы пишите просто статью, не спрашивая, что интересно в комментариях.
заголовок у вас цепляет, пИшите вы легко, ну так и выкладывайте статьи, а там поймете по интересу аудитории, что работает, а что нет :)
Иначе не сработает. Да и не забывайте, аудитория Хабра - строгая)) вас вон уже захейтили немного в каментах. Это нормально :)