[4/8] Managing Humans: Biting and Humorous Tales of a Software Engineering Manager (Как управлять интеллектуалами: я нерды & гики) (Рубрика Management)
Продолжаю рассказ обзором второй части "The Process is the Product", где автор рассказывает как хорошие процессы помогают предотвратить проблемы и катастрофы. Хорошие процессы придают структуру работы, а плохие - приводят к бюрократии, бессмысленным совещаниям, конфликтным ситуациям. Автор в 10 главах дает свои советы как сделать ваши процессы хорошими. (Предыдущие посты 1, 2, 3)
22) 1.0 В этой главе Рэндс рассказывает о том, что запуск версии продукта 1.0 всегда сложен (фактически, это создание стартапа). Он приводит метафору перевернутой пирамиды с 4 уровнями, где вы как эквилибрист балансируете ее на острие проекта
- Проект - содержит суть того, что вы хотите сделать и придает эффект срочности
- Люди - для запуска проекта нужна команда (но незаменимых людей в ней нет)
- Процесс -определяет коммуникацию людей
- Продукт - пока его нет, у вас нет компании Большинство стартапов не вывозят соблюдение баланса и вся пирамида разваливается 23) Мифы о процессе Процессы - это придумки менеджеров, что бесят инженеров. Пока компания была маленькой процессы были простыми и неформальными. Но по мере роста компании процессы усложняются. Это не нравится старой гвардии внутри компании, которая и без новых доработок в процессах ориентируется в том, что происходит. А новые процессы обычно создаются новой гвардией. Из-за этого происходит конфликт. Если обобщить хорошие процессы могут быть полезны, но важно понимать цель и суть каждого процесса - иначе это какой-то карго-культ. 24) Как начать? Рэндс рассказывает про то, как разложить большую цель на отдельные шаги и выполнять их. Эти шаги могут быть не всегда линейными и это ок. Главное снять давление большой цели, но проверять, что выполнение значительного количества шагов приближает к цели. Я сам использую этот подход для написания книги 25) Найти время на то, чтобы подумать Автор рассказывает про то, что руководители часто проваливаются в операционку и просто реагируют на события. Но надо отдельно подумать о том времени, которое можно выделить на то, чтобы подумать. Он предлагает проводить встречи
- мозговой штурм, посвященные большим проблемам, где происходит обсуждения
- прототип, где обсуждается прототип решения Важно отдельно контролировать принимаете ли вы решения, реализуете ли вы их (или только говорите) 26) Ценность "пропитки Хорошая идея о том, что для решения сложной проблемы надо дать ей время настояться в вашей голове. Сначала во время активной фазы надо закинуть в голову факты, идеи и контекст. А дальше во время пассивной фазы взять паузу и сделать так, чтобы мозг в фоне думал об этой проблем. Дальше к вам придет инсайт ... но это не точно. Я сам использую этот подход для презентаций и статьей 27) Фиксация контекста Автор предлагает фиксировать гениальные идеи. Для этого он использует метафору VCS (git). А меня это навело на мысли про ADR (architecture decision records) или лог решений 28) Теория капли Эта мысль сходна поговорке "вода камень точит" 29) Когда рушится мир Автор описывает подход работы в инциденте, где формируется командный центр, проводится анализ ситуации, предлагается первый план, он анализируется и дорабатывается, а потом применяется. Во время применения всех заинтересованных информируют о решении инцидента 30) О важности хакинга Это про дуальность компаний. Пока компания стартап она движется быстро и срезает углы в угоду скорости. Потом она растет и начинает ценить стабильность. Но даже так в ней должна быть нестабильная часть иначе можно пропустить подрывные инновации с рынка 31) Разрушители энтропии По мере роста компании могут понадобится хорошие проджект менеджеры. Плохие приносят только бюрократия и процессы ради процессов, а хорошие помогают построить качественные процессы:)
Продолжение в следующем посте.
#Management #Software #Engineering #SoftwareDevelopment #Processes #Leadership