Про преемственность поколений (#менеджмент)
Откопал артефакт 10ти летней давности, когда работал СТО в одном видном интернет-проекте. Масштаб команды на тот момент был сильно меньше тех, что находятся сейчас в зоне моих интересов и ответственности. Но, кажется, что за 10 лет ничего не поменялось, и в среднем по больнице многие конторы имеют примерно такие же проблемы. Орфография тех времен сохранена. Подумал и решил оставить это здесь, потому как каждый пункт достоин отдельного внимания, следом может выпущу постов на эти темы. Что бросается в глаза, так это всеобъемлющий спектр проблем - начиная с команды и заканчивая взаимодействием с бизнесом на самом высоком уровне. В воспоминаниях осталось то, что усилия были приложены очень серьезные, и большинство вопросов было закрыто, но потом в конторе сменился вектор развития и часть руководителей, что запустило этот список на второй круг. И, что характерно, даже спустя годы и опыт эти проблемы все-равно встают на регулярной основе в самых разных проектах и командах.
1. Нет анализа неудовлетворённости. Отдельно есть у ПО (продукт-оунер) и команды. Вместе нет.
2. Нет кроссфункциональности (штатного сложно заменить внештатным) - каждый раз трудности.
3. Текучка в командах, да и среди менеджеров.
4. Бессмысленные ретроспективы (по результатам надо ставить задачи. У меня есть отличные примеры ретроспектив тех.отдела).
5. Нет фиксированных циклов обратной связи. Демонстрации по праздникам плохая тема.
6. Процессы в некоторых командах плавают. В головах команды одни процессы - в головах менеджеров другие.
7. Сложно выкатить что-то работающее в конце итерации. Да и вообще сложно выкатить.
8. Слабо следим за очередями готовой работы (тесты подвисают, приёмка подвисает).
9. Слабо следим за одновременными задачами в работе. Иногда их много.
10. Не следим за договорённостями.
11. Туго с самоорганизацией.
12. ПО не горит желанием построить мост.
13. Сложный цикл принятия решения о функционале (долго можем утрясать с боссом, а потом рывком поменять в конце цикла).
14. Плохой процесс уточнения и планирования. Вечный спор за качество того, что мы называем требованиями.
15. Не всегда команда-команда.
Немного комментариев:
- в п.п.1 улыбнуло "анализ НЕудовлетворенности", а не "анализ удовлетворенности".
- в п.п.2 была попытка расширить штат за счет аустафа
- к п.п.3 также был найден еще один артефакт с причинами ухода сотруников - ничего не поменялось за эти годы
- к п.п.4,7,13,14 были попытки с разной степенью успешности внедрять скрамоподобные процессы, в итоге получилось что-то свое
- в п.п.12 был указан вполне себе конкретный мост, но смысл был имеено в мосте, а не названии
«Только дураки учатся на своих ошибках» говорим мы, но Рузвельт сказал чуть иначе «Только дураки учатся на своих ошибках, а умные на чужих».
Что я хотел сказать этим постом вместе с Теодором: во-первых, иногда очень полезно копаться в прошлом, чтобы попробовать не ошибаться в настоящем или будущем, во-вторых, мир разработки глобально не сильно изменился, проблемы решаются примерно одни и те же десятилетиями, а значит обращаться к прошлому опыту или чужому - крайне полезно. Литература, доклады, митапы, статьи на Хабрах, посты в телегах, все это формирует управленческий кругозор и дает ящик с инструментами, а также сценарии их использования и варианты развития событий.
Вот такое вот пятничное немного короче обычного получилось.
Откопал артефакт 10ти летней давности, когда работал СТО в одном видном интернет-проекте. Масштаб команды на тот момент был сильно меньше тех, что находятся сейчас в зоне моих интересов и ответственности. Но, кажется, что за 10 лет ничего не поменялось, и в среднем по больнице многие конторы имеют примерно такие же проблемы. Орфография тех времен сохранена. Подумал и решил оставить это здесь, потому как каждый пункт достоин отдельного внимания, следом может выпущу постов на эти темы. Что бросается в глаза, так это всеобъемлющий спектр проблем - начиная с команды и заканчивая взаимодействием с бизнесом на самом высоком уровне. В воспоминаниях осталось то, что усилия были приложены очень серьезные, и большинство вопросов было закрыто, но потом в конторе сменился вектор развития и часть руководителей, что запустило этот список на второй круг. И, что характерно, даже спустя годы и опыт эти проблемы все-равно встают на регулярной основе в самых разных проектах и командах.
1. Нет анализа неудовлетворённости. Отдельно есть у ПО (продукт-оунер) и команды. Вместе нет.
2. Нет кроссфункциональности (штатного сложно заменить внештатным) - каждый раз трудности.
3. Текучка в командах, да и среди менеджеров.
4. Бессмысленные ретроспективы (по результатам надо ставить задачи. У меня есть отличные примеры ретроспектив тех.отдела).
5. Нет фиксированных циклов обратной связи. Демонстрации по праздникам плохая тема.
6. Процессы в некоторых командах плавают. В головах команды одни процессы - в головах менеджеров другие.
7. Сложно выкатить что-то работающее в конце итерации. Да и вообще сложно выкатить.
8. Слабо следим за очередями готовой работы (тесты подвисают, приёмка подвисает).
9. Слабо следим за одновременными задачами в работе. Иногда их много.
10. Не следим за договорённостями.
11. Туго с самоорганизацией.
12. ПО не горит желанием построить мост.
13. Сложный цикл принятия решения о функционале (долго можем утрясать с боссом, а потом рывком поменять в конце цикла).
14. Плохой процесс уточнения и планирования. Вечный спор за качество того, что мы называем требованиями.
15. Не всегда команда-команда.
Немного комментариев:
- в п.п.1 улыбнуло "анализ НЕудовлетворенности", а не "анализ удовлетворенности".
- в п.п.2 была попытка расширить штат за счет аустафа
- к п.п.3 также был найден еще один артефакт с причинами ухода сотруников - ничего не поменялось за эти годы
- к п.п.4,7,13,14 были попытки с разной степенью успешности внедрять скрамоподобные процессы, в итоге получилось что-то свое
- в п.п.12 был указан вполне себе конкретный мост, но смысл был имеено в мосте, а не названии
«Только дураки учатся на своих ошибках» говорим мы, но Рузвельт сказал чуть иначе «Только дураки учатся на своих ошибках, а умные на чужих».
Что я хотел сказать этим постом вместе с Теодором: во-первых, иногда очень полезно копаться в прошлом, чтобы попробовать не ошибаться в настоящем или будущем, во-вторых, мир разработки глобально не сильно изменился, проблемы решаются примерно одни и те же десятилетиями, а значит обращаться к прошлому опыту или чужому - крайне полезно. Литература, доклады, митапы, статьи на Хабрах, посты в телегах, все это формирует управленческий кругозор и дает ящик с инструментами, а также сценарии их использования и варианты развития событий.
Вот такое вот пятничное немного короче обычного получилось.