Comments 36
Они начинают работать там, где уже есть:
общее понимание цели (масштаб, качество, скорость)
Хочется не согласиться.
Выше по тексту сформулирована проблема - "никто не слушает, что разработка не успевает" и "три источника - маркетинг, продажи, бухгалтерия" - каждый продавливает свою задачу.
Когда мы говорим, что для того, чтобы процессы заработали нужно "общее понимание" и "доверие" мы как будто бы ждём, что три источника задач (на самом деле - даже четыре - разработка в описанных условиях наверняка генерирует техдолг, который рано или поздно надо начинать "выплачивать") - договорятся и выровнятся друг с другом по приоритетам.
Но ведь, если бы источники задач могли бы между собой договориться - нам не нужны были бы никакие формальные процессы!) Они бы просто договорились)
В описанной ситуации непонятно, а было ли что-то, что МЕШАЕТ и ЗАПРЕЩАЕТ условному самому-главному руководителю маркетинга/продаж/бухгалтерии прийти и принести +1 задачу?
"Просто договориться", увы, не выходит, так как каждый педалирует свои интересы, для этого и хочется наладить процессы, некие правила создать, чтобы упорядочить хаос)
мне помогало прямо очную ставку делать. я описывал свое видение в какой последовательности надо делать задачи и почему. дальше приглашал всех заказчиков из разных департаментов и объяснял им, что ресурсов есть только на одну задачу за раз, поэтому придется выстроить очередь, поэтому чтобы сохранялось доверие и прозрачность, предлагал им между собой согласовать порядок выполнения задач
в целом в матричной структуре команд разработки, когда у меня в какой-то момент не было инженеров под мой продукт я так же ходил к другим продуктам и просил их уступить инженерные слоты под мои задачи
мне кажется, что такое может сработать и здесь
у нас создан проектный офис, в котором менеджер как раз призван фильтрован задачи, которые поступают из других отделов на разработку, договариваться с ними о приоритетах. Когда это задумывалось, все выглядело радужно, но на деле пока не так
ну по моему опыту в таких ситуациях "специально выделенный человек" может добавлять неопределенности и лучше чтобы такие встречи вел продакт или проджект команды которая будет все реализовывать - чтобы на лету отвечать на вопросы и возвращать к основному вопросу. сторонний человек может упустить либо технические особенности проекта, либо его связи с бизнес-заказчиками.
был опыт когда специально нанятый руководитель проектного офиса пыталась разруливать поток задач и это вылилось как раз в то, что она просто выдала каждому заказчику тонну форм для подготовки ко встречам на которых она не понимала толком ни о бизнесе, ни о технической реализации. в итоге часть команд просто между собой обо всем договаривалась и на такие встречи приходила с решенным вопросами. а другие просто сказали, что для них это не сработало
ну раньше мы сами (я, в частности,) решали все вопросы приоритезации с непосредственно иницааторами, сейчас менеджер из проектного офиса все равно приходит ко мне или БА с миллионом лишних вопросов "а что да как, а почему работает так, а не этак, а накатим ли скрипт и пр.". Либо это было неверным решением, либо еще не до конца обкатали новый процесс.
# Было
У царя 3 сына:
старший (умный детина);
средний (так и сяк);
младший → вовсе дурак.
---
Просто же список за списком! Ровно как вы в статье рассуждаете о том, что голый процесс, вброшенный в хаос/вакуум, ничего не решает и нуждается в "мясе" вокруг него: культуре практиках, ритуалах - ровно так же и статья поверх структуры и тезисов нуждается в мясе из рассказа, составленного из предложений, содержащих подлежащее, сказуемое и прочую светотень. Будто чей-то рабочий блокнот на экране открыл, где что ни страница, то чек-листы и буллиты, имеющие отношение к какой-то объёмной задаче, оставшейся за пределами этой исчёрканной бумаги.
Нечитабельно. Слишком много ии?
Пфф... Перегруженными процессами и их схемками увлекаются только незрелые люди, которым нечего делать. Если у управленца есть некоторый опыт, он берёт минимальный работающий процесс, тюнит его под ситуацию, и команда "просто работает". Ну а потом можно и схему нарисовать (а можно и не рисовать - всем и так всё ясно).
P.S. в статье слишком много списков!
Что значит "просто работает"? Не думали ли Вы, что у команды из 16 человек мозги работают по-разному, как и у остальных сотрудников компании? Чтобы каждый не работал так, как он видит (из разряда "я- художник, я так вижу"), нужен общий регламент, как и в любом бизнес-процессе. Нужна структура, рамки заданные.
Увы, не всем все ясно, ясно может быть только в голове у того, кто это придумал.
Что значит "просто работает"?
Это значит, что каждый знает, что делать, и делает. А что делать, изначально доносит руководитель.
Напротив, когда возникает идея сходу нарисовать Огромную Схему Процесса, она обычно слабо соотносится с реальностью, особенно если рисуется в деталях. И особенно, если рисующий не спец во всех этих деталях.
Вот здесь https://habr.com/ru/articles/991958/comments/#comment_29486842 Aldaris_73 хорошо расписал. Идея итеративной настройки процесса тоже хороша, но общая суть в том, что на практике оказывается первичен процесс, а не его подробное описание (хотя, казалось бы, должно быть наоборот).
процессы часто не работают не потому, что они плохие или их нет, а потому что
.... а потому что вы их не умеете готовить.
Пример буквально абзацем ниже:
регламенты прочитали и забыли, никто не хочет работать по новой инструкции
Естественно никто не хочет формализации и все будут саботировать. Но если у вас процесс заканчивается на хоровом чтении регламента "за все хорошее и против всего плохого" то вот он, плохо приготовленый процесс.
Тут сто пятьсот причин может быть...
нон-стоп-дедлайн, это когда продавать ключевому клиенту успевают быстрее, чем команда пилит фичи
для каждого следующего шага по процессу нужно по пол-дня бегать за человеком, без которого он не делается
комплиментарная к предыдущей - свои задачи висят, и по двадцать отвлечений на дню на шаги процессов у других людей (обычно когда RACI матрица забита буковками до верху)
больше отчётов богу отчётов
В общем пока у команды производительность минимум на четверть не превышает поток задач - никакие процессы ввести не удастся. Плавали, знаем.
Спасибо за комментарий! Безусловно, причины есть и другие, с теми же дедлайнами, нескончаемым потоком задач и еще не будем забывать про личные факторы, все-таки с людьми работаем). Хочется верить, что проблем станет меньше.
ну если исходить из Теории Ограничений, то производительность практически никогда невозможно натянуть на бизнес требования. именно поэтому более реалистично сперва скомпенсировать бизнес требования под текущие ресурсы потому что "скорость всего процесса равна скорости самого узкого места", а когда узкое место найдено и оценено, то уже зная это ограничение работать с задачами заказчиков и возвращать им реалистичные сроки
Процессы работают тогда, когда направлены на результаты. А для этого надо сначала выяснить на каком этапе и какая проблема формируется. И только потом внедрять шаги, позволяющие их решить или компенсировать вред. Четко понимая как конкретные шаги смогут это решить.
В текущем повествовании ощущение, что пытаемся решить проблемы в финальной точке, не разобравшись откуда они появляются. Просто внедряя обобщенные правильные процессы как у всех, для решения неправильных проблем. Приглашение внешнего эксперта не знающего внутренней кухни и оценивающего всё по верхам (общая температура по больнице) в ту же степь.
"В соседней компании поют гимн по утрам и у них продажи выше на 20%. Начнем тоже петь гимн и продажи подскочат"
Вы сами пишете, что ваши топы продают сроки клиентам даже без консультации с профильными экспертами отвечающими за эти сроки. С одним этим никакие процессы в команде не позволят успевать.
Далее команда, у которой мотивация на таком уровне, что они не хотят уже никакие регламенты и процессы. Или логически не понимают как это способно помочь решить те самые проблемы.
И расписывать можно долго. Ну реально, всего 16 человек. Вы не можете собраться и поговорить открыто, выслушав каждого?
Могу только предположить что руководству, которому не интересно мнение команды по срокам, скорее всего и по всему остальному их мнение не учитывает и не пытается слушать.
Вы так хорошо все говорите)) Не могу не согласиться. Со стороны все кажется просто, а на деле, если погрузиться, там стооооолько всего еще).
Да я и не говорил что это просто) Уходят месяцы, а иногда и годы. И чаще всего основное сопротивление исходит сверху. Когда нужно найти виноватых и все исправить, но это все должно быть найдено обязательно в низших эшелонах. А в итоге, как в том анекдоте - в любом расследовании главное не выйти на самих себя. И вот это исправить уже самое сложное.
Процессы в продуктовой команде очень хорошо работают, просто есть одно ограничение - ваш PO должен понимать куда движется ваш продукт/ы и иметь виденье куда вых хотите придти. Если этого нет, никакие процессы в этом не помогут.
Работаем над этим)
ну ещё PO должен иметь защиту от влетов за счёт того, что стратегия продукта согласована всеми, и он сам, или кто-то выше по иерархии может (вежливо, но твердо) слать нахрен тех кто лезет невпопад
Тут и да и нет. В зависимости от типа управления, я могу выделить примерно 6 типов:
Команда → процессная / функциональная
Инициатива → проектная
Продукт → продуктовая
Организация → матричная
Бизнес в целом → портфельная (если >1 проекта)
В зависимости от типа управления, и структуры CLVL: видение, стратегия, а также риски будут по-разному разделены между управляющим составом.
Но в любом случае PO/ CPO будет нести основную ответственность.
надо прокачивать тут софты))
Спасибо, хорошая статья и глубокие мысли, переживание за результат.
Я бы добавил к смыслу процессов ещё возможность уравновешивания влияния конкретных личностей на результат.
Возможно эта мысль помогла бы и выстроить процессы получше. Поясню. Берём успешного человека, который тянет команду и решает задачи, который когда уходит в отпуск - все замирает.
Раскладываем его деятельность на процесс и шаги. Выбираем оптимальных исполнителей для каждого шага.
Вуаля.
Классная статья, содержательная. Спасибо, что поделились своим опытом и сложностями, с которыми столкнулись. Ждем следующий этап и его итоги. Желаю успешно прийти к нужной цели!
Арррр... ну что ж вы в самом деле - какие-то сапожники без сапог.
Поясняю:
Обычно продукты и проекты растут итерационно через проверку гипотез, фокус-группы и описание ИКР (идеальный конечных результатов).
Вы так работаете: взяли идею, прикинули ИКР, выписали из этого MVP, сделали, проверили, накинули мысли с ретро, пошли в след. итерацию. И так далее, и тому подобное.
Что ж вы свои РАБОЧИЕ операционные и проектные дела не делаете так же?
Это такой же проект ведь по сути.
Поясню на пальцах: процесс - это ОПИСАНИЕ того, что уже РАБОТАЕТ. Его фишка в том, что вы документируете то, что РАБОТАЕТ так, КАК ВАМ НУЖНО. С хрена ли вы решили, что способны придумать процесс, который сразу заработает? Процессы как феномен - нужны если вам нужно сделать человеконезависимые задачи, ЛИБО если требуется масштабирование успешного опыта. Условно - если ваш Вася Пупкин кто умеет круто раскатывать релизы на прод - уволится, заболеет или умрет, то ваша работа встанет. Т.к. только он может в крутую раскатку. А чтоб нащупать этот способ пройдет время. Вот вы и документируете опыт Васи в процессе. Чтоб условно любой человек со схожими компетенциями мог в такую же работу с таким же результатом. Процесс - это про воспроизводимость действий.
Но если вы что-то делаете впервые. Если вы не знаете точно выстрелит ли это точно или нет - вам нужен проект. Это про ограничения, про критерии качества выполнения работ, про зоны ответственности ЗА ТАКОЙ ЭКСПЕРИМЕНТ.
Соглашусь тут с автором, что важна определенная зрелось в компании. Это задачи про преемственность опыта, отработку ошибок, ретроспективный взгляд на проходящие и достижение целей.
Пока компания растет (есть признаки) или развивается - ей не до процессов. Важна скорость. Поэтому куча решений принимается в моменте, экспериментально, на свой страх и риск.
Соответственно - для молодой компании - нормально, если её деятельность это одни проекты, и никаких процессов.
Но когда компания замедлила рост, задалась вопросами а можно ли делать эффективнее то, что уже есть и стабильно генерирует прибыль или дает результат, или нам нужно идти в масштабирование на другой город, другой офис и других людей исполнителей - то вот тут уже и нужны процессы. При чем сперва описанные как есть. А потом (тривиально) to be.
Мораль:
зря вы полезли описывать то, чего нет. Вам бы проектик сперва запустить для теста идей да гипотез. Чтобы найти способ как это заработает и погонять пару месяцев.
И лишь тогда в процессы идти.
З.з.ы. Это мое имхо. Без обид, пожалуйста.
Спасибо за развернутый комментарий. В целом согласна: процессы имеют смысл тогда, когда есть что стабилизировать и масштабировать. В статье я скорее описывала целевое направление и рамки, а не попытку «угадать» идеальный процесс с нуля. С тезисом про «процесс как фиксацию работающего» согласна тоже. Моя идея была в том, что даже на стадии проектов полезно иметь минимальные опорные договорённости, чтобы эксперименты не превращались в хаос)
Почему процессы в продуктовой IT-команде не работают