Комментарии 10
Кто, когда и как вносит терминологию в новый проект.
До начала проекта, мы вот уверены в нашей способности поставить чёткие, измеримые цели?
Всё лежит на вашем опыте и чуйке, ошибки неизбежны, почти всё зависит от вашего реноме и способности держать удар на постановочном совещании.
Умение увидеть риски, да ещё и оценить их корректно при старте проекта... Высший пилотаж. А ещё и способность не побояться их донести и убедиться что услышали...
Сложно что-то добавить, но легко превратить в микроменеджмент
Где та грань или область, сумеречная зона, за которой начинается микроменеджмент, а перед которой, отсутствие коммуникаций
Ох, повеяло СМК, плохо выбранные измеримые показатели, точно лучше отсутствия? По мне - да.
Поставить на первое место. Но помнить, это всё равно ничего не значит, однако лично менеджеру конечно спать будет легче.
Любой член команды может внести новый термин в проект. Главное, в случае обнаружения расхождений в понимании, зафиксировать это расхождение, устранить его и внести термин и его определение в условный "словарь". А можно и не в условный, а в соответствующий документ.
А стоит ли начинать новый проект без чёткой измеримой цели? Если нет чёткого понимания, для чего это всё делается, и способа измерить, в правильном ли направлении дело движется, то проект де-факто делается исключительно для попила бюджета. И даже в этом случае, можно сам факт попила сделать целью. Чёткой и измеримой, пусть и неформальной/скрытой от заказчика. "Попилить N миллионов рублей командой из X человек за T месяцев".
На самом деле многое лежит на умении грамотно составить SoW (ТЗ), управлять доступными ресурсами и работать с изменениями, точнее запросами на изменения. Что гораздо более чётко формализуемо, чем "чуйка".
Очевидные риски известны. На них натыкались многие уже много-много раз. Предусмотреть и закрыть или принять их можно. Всё не предусмотришь, но многое - вполне.
Это очень разные понятия.
Примерно там, где находится понимание отличий управления от общения. Свобода принятия решений в способах выполнения поставленной задачи (причем, задача может быть поставлена крайне широко) совершенно ортогональна неправильному пониманию поставленной задачи, отсутствию своевременных отчётов о статусе задачи, или возникших препятствиях в её решении. Она даже отличается от разрешения/приказа начать выполнять задачу после принятия решения о том, как её выполнять. Советую книгу "Turn the ship around!" - она как раз про это, на самом деле. Или в основном про это.
Управление изменениями - это не только и даже не столько про OKR (я надеюсь, Вы же не KPI имели в виду под измеримыми показателями?). Подавляющее большинство изменений не затрагивают OKR, но затрагивают методы их достижения.
Документирование ничем не важнее понимания целей проекта и его содержания внутри команды, грамотного планирования и менеджмента. Внутри маленькой команды, делающей небольшой проект, вполне можно достичь успеха без хорошей внутренней документации. Но вот формальное документирование без понимания, планирования и управления разве что и сможет, что с какой-то степенью успешности прикрыть зад менеджера, да и то без гарантий. Ибо провал проекта, даже грамотно прикрытый документацией, редко становится плюсом в репутацию управленца. Документирование хорошо как метод достижения пунктов 1-7, если выполняется грамотно.
Не книжки читать не буду )) - я ни разу не менеджер, просто опыт жизненный, про OKR представления не имею, но KPI не имел ввиду точно.
На самом деле все пункты представленные в статье - хорошие и верные. Мне хотелось, чтобы автор поста несколько напрягся и от красивых лозунгов продвинулся чуть глубже, пытаясь ответить.
По п. 2 - ни из статьи, ни из вашего ответа, так и не становится яснее, каким чудом, на этапе начала проекта формулируются "чётко измеримые" цели - чёткие и измеримые ))) Проект новый, безусловно есть проблемы у бизнеса, но мы наверное не хотим просто взять бумажку, выписать на неё проблемы, пронумировать и сказать вот цели, а в скобочках написать ожидаемое значение целей...
Предельные значения ситуаций понятны:
- а давайте замутим вот такую классную штуку - а давай
- а давайте распилим бюджет - а давайте
Интересней, что делать между этих двух предельных ситуаций
Очевидно же, что цель статьи в перечислении ошибок, а не в подробном описании того, как их избежать. И в этом отношении статья вполне хороша, а других задач в ней не наблюдается. Конкретно по целям и метрикам - это даже не статья, а серия статей или книга получится, чтобы раскрыть как же их готовить. Впрочем, тут по каждому пункту понадобится своя большая статья, чтобы хоть как-то раскрыть тему.
Но если вкратце, то "а давайте новую классную CRM внедрим, как-то с клиентами отношения не очень" - это цель фиговая, но как стартовая точка обсуждения пойдёт. Через обсуждение того, что же конкретно значит "с клиентами отношения не очень", можно выйти и на чёткость формулировки и на измеримость показателя.
Например, отношения фиговые, т.к. много клиентов не собираются продлевать контракт на следующий год. А "много" это сколько конкретно? 30 процентов. А сколько нормально? Обычно 10-15% было. Вот тебе конкретная измеримая цель. Как будем достигать, давайте думать, что может изменить ситуацию и как это повлияет на другие показатели компании, прежде всего финансовые (главная задача бизнеса - извлечение прибыли, не стоит об этом забывать). Может, дело не в CRM вообще?
Или количество заявок с негативным сентиментом (прошу прощения, в последние годы я работаю зарубежом и несколько забываю русскую терминологию) растёт. Но если покопаться, то растёт оно прежде всего в связи с обшим ростом количества клиентов и практически не сказывается на других показателях. Люди ругаются, но продолжают пользоваться и платить, поэтому проблема не критичная и бросать все ресурсы на её решение может быть неразумно.
В общем, стоит только задаться целью перейти от общих слов к конкретному описанию конкретных проблем, а там уже на измеримые показатели выйти можно. Не всегда легко, но никто не обещал, что будет легко.
Так что, нет, мы не хотим просто взять бумажку и что-то туда формально записать, мы действительно хотим понять проблемы бизнеса. А это как раз и означает переход от общих слов к конкретным проблемам и связанным с ними метриками. Бизнес в целом управляется по метрикам, поэтому это в любом случае полезно.
Всё так. Именно, если поднапрячься, то из любой "странной хотелки", через общение и разговоры можно вытянуть и "рельную" цель и "реально" измеримые показатели.
С бумажки я тоже всегда начинаю, а потом медленно и настойчиво выхожу на что-то более внятное. Очень часто подсказывая и направляя, решение за заказчиком, но помочь ему очень даже можно и нужно.
Вот только всё это я и называю "чуйка" - ибо каждая "хотелка" должна превратиться в набор "целей с измеряемыми показателями". Но что кроме "чуйки" может нас привести к более хорошим, а не к менее хорошим наборам...
Правда, моё мнение, что набор "так себе целей и показателей" всяко лучше чем их полное отсутствие
Так в том-то и дело, что это ни разу не "чуйка", которую руками не потрогать и не передать другим в виде знания. Это набор методов и навыков, которые вполне себе формализуются и передаются через обучение.
А чем отличается "так себе цель" в виде "внедрим CRM" или "давайте забубеним классную новую фишку" от отсутствия цели? ИМХО, только тем, что кто-то по глупости может на неё бюджет выделить, т.е. это может принести даже больше вреда, чем полное отсутствие цели, т.к. в случае отсутствия цели хотя бы бюджет останется.
Сейчас с этим GenAI все носятся и утверждают, что клиенты не купят никакого решения, если в нём нет слов GenAI. По крайней мере в стране, в которой я сейчас работаю. С точки зрения исполнителя - ОК, попил бюджета на хайповой теме, заказчик-барин. Но заказчикам бы не мешало подумать, а в чём их польза будет в конкретных цифрах. ИМХО, хороший пример "так себе цели", требующей больших ресурсов, но далеко не всегда способной хоть как-то себя окупить.
Ставлю вам(+) в карму , так как тянет на серию , - можете по каждому пункту рассказать реальные история из своей проектной жизни , и обязательно с юмором.
Скучные тексты нечитабельны в мире gpt контента
Казалось бы, очевидные факты. Но нет.
Насчёт сроков (сделаем за 2 недели, по факту - 2 месяца): припуск делать всегда в свою пользу.
Ох, единая терминология это действительно важно. Не думал, что кто-то будет писать об этом. Иногда встречаю случаи, когда люди в одной команде используют разные термины для одних и тех же обозначений, и сами же в них путаются. В таких случаях важно обсуждать с командой, какие термины лучше использовать или хотя бы уточнять, что конкретно они имеют ввиду.
8 типичных ошибок при работе над проектом, которые может допустить каждый (но теперь не вы) :)