- Главная
- →
- Управление командой разработки (тимлиды)
Решение 5 проблем в управлении разработкой Управление командой разработки (тимлиды)
Топ-менеджер с 20-летним опытом работы в различных IT-компаниях (подробнее здесь: https://www.linkedin.com/in/pletenevandrey/).
Специализация и интересы: управление производством ПО (продуктовая, заказная разработка, аутсорсинг), управление проектами, управление персоналом, личная эффективность руководителя.
Тезисы
Консультируя IT-компании, я вижу, как команды с разной культурой, разными подходами, разной историей совершают одни и те же ошибки. К сожалению, это не разовые ошибки, которые делаются случайно. Это bad practices - стереотипы контрпродуктивной работы, которые формируются "сами собой", в отсутствие опыта построения производства ПО. Почему паттерны программирования являются нормой, а построение процессов разработки в компании выглядит как постепенное изобретение велосипеда? Потому что обмен людьми и практиками в управлении происходит гораздо медленнее чем в программировании.
Давайте уменьшим число "изобретателей" хотя бы на количество участников HighLoad. Приходите на мой доклад, если вам знакома хотя бы одна из следующих проблем:
1. 80% задач имеют одинаковый приоритет - высший.
2. Количество фич в продукте растет, но клиенты недовольны.
3. 90% времени задача находится в состоянии "выполнена на 90%".
4. Как ни планируй, все идет не так.
5. Все задачи успешно прошли тест, но продукт не работает.
6. Все задачи выполнены, а заказчик не принимает проект.
7. Не получается обосновать начальству необходимость рефакторинга.
8. Команда недовольна и приходится их просить.
9. Овертаймы зашкаливают.
10. Завтра релиз, а он ушел в 18:00.
11. Нанимаем все больше тестеров, а багов все больше.
12. Саппорт съедает все ресурсы. Не остается на развитие.
13. Не укладываемся в сроки, а они сидят "вконтакте".
14. Работаем по скраму, а заказчику нужен календарный план с этапами.
15. Все ему разжевал, а он сделал все равно не то, что нужно.
16. У нас все работает. У клиента - нет.
17. Вторые 90% проекта идут гораздо хуже, чем первые 90%.
18. Нужно сдвигать сроки, а начальство об этом слышать не хочет.
19. Код нестабилен, а заставляют релизить.
20. У меня не хватает авторитета в команде.
Мы разберем причины этих проблем и поделимся друг с другом опытом их решения.
Укажите в комментариях к докладу номера проблем, которые вы хотели бы разобрать. Топ-5 я включу в доклад.