Здесь ключевой аспект — планирование. И ответ зависит от того, кто этим процессом управляет. Если планирование задач находится в зоне ответственности руководителя проекта, то вопросы, конечно, к нему.
От проекта к проекту критерии готовности к разработке и критерии завершенности не очень сильно меняются, мы описываем их как часть проектной документации для заказчика. Команда уже и так знает эти критерии, они в том числе описаны в нашем внутреннем документе как флоу работы над проектом. Команде достаточно управлять фичами проекта как сторями с помощью статусов в таск-трекере, дейли, синхронов и ретро. Не хотим плодить лишнюю документацию, например, чтобы разработчик прорывался сквозь текст вместо того, чтобы фокусироваться на работе) Возможно, это тема для следующей статьи) Спасибо за идею)
Под "сервисом" имели ввиду разрабатываемый программный продукт. "Архитектура" — как слой бизнес-логики приложения, карта функций системы, разбитых на бизнес-блоки. Возможно, слово "сервис" могло немного запутать, поэтому удалили его)
Планирование задач команды мы также советуем делать заранее, чтобы утром любой специалист понимал, что он будет сегодня делать. А что касается менеджеров, тут, на нашем опыте, более адаптивно планировать день с утра, включая входящие утренние задачи от заказчиков.
Вы правы) Советы, которые описаны в статье — это базовые составляющие, которые будут полезны для напоминания как для тех, кто уже в профессии давно, так и для новичков в ней)
Information
Rating
Does not participate
Location
Калининград (Кенигсберг), Калининградская обл., Россия
Здесь ключевой аспект — планирование. И ответ зависит от того, кто этим процессом управляет. Если планирование задач находится в зоне ответственности руководителя проекта, то вопросы, конечно, к нему.
От проекта к проекту критерии готовности к разработке и критерии завершенности не очень сильно меняются, мы описываем их как часть проектной документации для заказчика. Команда уже и так знает эти критерии, они в том числе описаны в нашем внутреннем документе как флоу работы над проектом. Команде достаточно управлять фичами проекта как сторями с помощью статусов в таск-трекере, дейли, синхронов и ретро. Не хотим плодить лишнюю документацию, например, чтобы разработчик прорывался сквозь текст вместо того, чтобы фокусироваться на работе) Возможно, это тема для следующей статьи) Спасибо за идею)
Под "сервисом" имели ввиду разрабатываемый программный продукт. "Архитектура" — как слой бизнес-логики приложения, карта функций системы, разбитых на бизнес-блоки. Возможно, слово "сервис" могло немного запутать, поэтому удалили его)
Интересно, спасибо)
спасибо, рады, что было полезно :)
а что вас смутило?)
Спасибо большое, рады, что понравилось!)
А почему решили пойти работать системным аналитиком, а не программистом?)
Спасибо вам!)
Спасибо, рады, что понравилось :)
Спасибо вам!)
Софт-скиллы на позиции лидов и правда играют большую роль)
Да, всё так, Алексея тянуло именно к кодингу, хоть аналитика, возможно, и правда была бы проще для перехода)
Спасибо за комментарий!) Планирование, делегирование и контроль — базовые харды, которые как раз транслирует Александр Фридман).
Планирование команды, разрешение конфликтов, понимание, как правильно построить коммуникацию, чтобы обеспечить нужный результат — это тоже основа, которой мы обязательно поделимся в следующих статьях. Материал большой, потому делимся порциями). Например, Ирина писала отдельную статью про то, как правильно коммуницировать с заказчиком: https://vc.ru/life/458828-instrukciya-dlya-prodzhekt-menedzherov-kak-vystroit-effektivnuyu-kommunikaciyu-s-zakazchikom
Планирование задач команды мы также советуем делать заранее, чтобы утром любой специалист понимал, что он будет сегодня делать. А что касается менеджеров, тут, на нашем опыте, более адаптивно планировать день с утра, включая входящие утренние задачи от заказчиков.
Что именно?)
Вы правы) Советы, которые описаны в статье — это базовые составляющие, которые будут полезны для напоминания как для тех, кто уже в профессии давно, так и для новичков в ней)