Откопал артефакт 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 был указан вполне себе конкретный мост, но смысл был имеено в мосте, а не названии

«Только дураки учатся на своих ошибках» говорим мы, но Рузвельт сказал чуть иначе «Только дураки учатся на своих ошибках, а умные на чужих».  

Что я хотел сказать этим постом вместе с Теодором: во-первых, иногда очень полезно копаться в прошлом, чтобы попробовать не ошибаться в настоящем или будущем, во-вторых, мир разработки глобально не сильно изменился, проблемы решаются примерно одни и те же десятилетиями, а значит обращаться к прошлому опыту или чужому — крайне полезно.  Литература, доклады, митапы, статьи на Хабрах, посты в телегах, все это формирует управленческий кругозор и дает ящик с инструментами, а также сценарии их использования и варианты развития событий. 

Вот такое вот пятничное немного короче обычного получилось.