"Комната с опускающимся потолком"... / Устюжанин Игорь (СКБ Контур)
•Als PPT, PDF herunterladen•
0 gefällt mir•466 views
Все команды, работающие над продуктами, уже заполучившими своих клиентов, постоянно разрываются между двумя видами задач: развитие и сопровождение существующего. В докладе раскрывается взгляд на природу этих процессов. На основе опыта работы нескольких команд делается попытка ответить на вопрос: как можно попробовать обуздать задачи сопровождения, которые пытаются поглотить весь ресурс команды, не оставив ничего на развитие?
Empfohlen
Weitere ähnliche Inhalte
Mehr von Ontico
Mehr von Ontico (20)
"Комната с опускающимся потолком"... / Устюжанин Игорь (СКБ Контур)
- 2. Несколько вводных замечаний • Ответственность руководителей проектов продуктов • Вскроем природу • Все сказанное - ИХМО
- 4. Шаг индукции
- 5. Кризис
- 7. ?Что делать Бдить • Всегда видеть границу распределения • Знать природу задач сопровождения
- 8. ?Что делать Выстроить отношения • Не делать фигни • Сопровождение требует затрат
- 11. ?Что делать Делиться работой • Разработчики должны создавать новое • Вынос часто изменяемых частей в инструменты
Hinweis der Redaktion
- С одной стороны буду говорить простые вещи, но: Вещи, о которых я буду рассказывать я считаю зоной ответственности менеджеров разработки. Людей, возглавляющих и представляющих команду разработки. Важно, что это услышат не только менеджеры разработки, а все участники процесса создания программного обеспечения Вскроем природу происходящего, тогда как многое становится заметным уже на более поздних стадиях. Часто лечится симптом, а не причина. Основная ответственность за управление теми аспектами, которые тут будут изложены мною возлагается на менеджеров разработки. Все сказанное далее – это ИХМО.
- Команда разработки не существует в вакууме. Есть люди, учавствовашие на старте проекта (в основном это директорат), есть клиенты, есть собственно участники команды. Все эти люди имеют рациональное, а чаще эмоциональное представление о динамике развития продукта. Где-то динамика меряется количеством фишек, которые добавляются в продукт, где-то функциональными модулями, или чем-то еще. В моих двух последних проектах, в которых я участвовал тоже были ожидания: Billy (количество подключенных продуктов в единицу времени) БК. Наращивания функционала (сначала один вид налогового режима с упрощениями, потом другой и т.д.) Все хотят видеть как минимум первый вариант, лучше – третий. Второй – это вариант, вызывающий вопросы.
- До t0 весь ресур команды тратится на создание новых фич После t0 – есть клиенты, есть сопровождение. В командах – дежурные программисты, бетмены, задачи на срочную правку багов, соответсвие законодательству и т.д. Если итерацию делаем что-то новое, что это новое в следующую итерацию ложится бременем сопровождения. По большому счету это функция от времени.
- Проявления кризиса: Внешний мир и прочие заинтересованные начинают выражать недовольство. Темпы упали, непонятно чем занимается разработка. Расслабились. Команда не может загружать задачи разработки. Почти весь ресурс уходит на сопровождение. Начинаются проблемы в команде. Сильные разработчики голодают по интересным задачам.
- Обычно просто увеличивают команду Но это не решает проблему. Это лишь дает глоток воздуха. Честно: это вообще не решает проблему, так как команда набирается постепенно.
- Бдить за границей. Понимать распределение ресурсов в команде, следить за динамикой происходящего и вскрывать природу задач, приходящих как сопровождение.
- Выстроить отношения с директоратом (спонсоры, заказчики и т.д.). Заказчики должны знать про распределение ресурсов Не делать фигни
- Это позволяет с одной стороны получить скачок «вниз», с другой стороны «выположить» кривую
- Максимально делиться возможностями решать задачи развития продукта с другими участниками (неразработчиками). Выносить в инструменты все что можно вынести, высвободить разработчиков. На первых итерациях важно все пережить самим, но после обязательно отдать на сторону.