Кирилл Лебедев
@Askofen
Руководитель группы разработки, Social Quantum
Information
- Rating
- Does not participate
- Location
- Санкт-Петербург, Санкт-Петербург и область, Россия
- Registered
- Activity
Руководитель группы разработки, Social Quantum
Information
Зачем нужен менеджер в IT проекте и что будет происходить когда его нет
Я привёл лишь пример, при котором предлагаемая Вами схема коммуникации очень быстро будет перегружена.
Я с этим не спорю. Я лишь показываю, что в качестве Заказчика может выступать коллектив людей, и эти люди могут иметь разную специализацию.
Этот пример показывает, насколько важно налаживать коммуникацию между представителями Заказчика и представителями Исполнителя. Входе реализации проекта коммуникациями нужно управлять, а не замыкать их на одного или нескольких менеджеров. Нужно устанавливать горизонтальные связи «специалист — специалист».
Если документация выполнила свою задачу, и в неё больше никто не заглядывает, то её бесполезно менять. Другой вопрос — должны последовать изменения, которые затрагивают работу других людей. Например, изменены условия задачи для программиста (или поставлена другая задача), а также — должны быть обновлены тест-кейсы. Последовательность и каналы информирования других заинтересованных лиц должны быть предусмотрены в плане коммуникаций.
Зачем нужен менеджер в IT проекте и что будет происходить когда его нет
Распределённая работа позволяет убрать эффект «бутылочного горлышка», но требует управления коммуникациями и синхронизацией между членами одной команды и разными командами.
Представьте себе, что Вы участвуете в проекте, работу над которым ведут одновременно 100 человек, распределённых по разным командам, а команды находятся в разных городах и на разных континентах. Насколько тогда хватит одного менеджера-коммуникатора?
Тут я с Вами не согласен. Наоборот, считаю, что если программист работает над реализацией определённой фичи, то ему нужно коммуницировать с продюсером, который эту фичу придумал и описал. Не все аспекты фичи можно заранее прописать в документе. Иногда возникают вопросы. И если вопрос возник — самое время обратиться к автору фичи. Если это сделать через менеджера, то он, скорее всего, пропустит мимо ушей определённые тонкости, т.к. не он реализует фичу и не он является её продюсером.
Также если смежную фичу реализует другой программист из другой команды, то первый программист должен обязательно с ним общаться, т.к. есть пересекающиеся места в коде, в архитектуре. Технические решения нужно согласовать.
Синхронизация осуществляется довольно просто. Программист обращается к продюсеру с каким-нибудь вопросом по фиче, продюсер даёт ему ответ, а затем — если необходимо — вносит изменения в документацию по фиче и/или в условия задачи.
Следует различать менеджера проекта и продуктового менеджера. Менеджер проекта не вмешивается в вопросы дизайна фичи и в вопросы технической реализации. Его интересует скоуп работ, сроки, ресурсы. А менеджер продукта — да, как раз занимается фичами. Если требуется продуктовый менеджер на стороне исполнителя, то согласен — вопросы к продюсеру проекта со стороны заказчика можно задавать через него.
Зачем нужен менеджер в IT проекте и что будет происходить когда его нет
Если ПМ станет единым контактным лицом для всех, то он быстро превратится в «бутылочное горлышко», в результате чего весь процесс разработки застопорится, т.к. все будут ждать его решения, а он хронически будет не успевать.
Кроме того, он ещё рискует превратиться в «испорченный телефон», т.к. вольно или невольно будет искажать детали задачи. Наоборот, лучше, когда по конкретной задаче разработчик коммуницирует с представителем заказчика напрямую, а в случае необходимости выполнения отдельной задачи, которая не учитывалась при оценке проекта, её нужно вносить в систему контроля задач и помещать в бэклог. Новая задача только тогда поступает на выполнение, когда она согласована ПМ с соответствующим представителем заказчика.
Зачем нужен менеджер в IT проекте и что будет происходить когда его нет
Согласен. Возьмём для примера издателя видеоигр, у которого во владении есть несколько игровых студий. Для чего нужен пример? Поясню ниже.
Издатель формирует свою линейку игр. Он решает, что через год или полтора в апреле месяце должна быть выпущена игра по определённой тематике. Таким образом, определяются сроки выпуска игры, длительность её разработки, тематика и, вероятнее всего, есть какие-то прикидки по бюджету. После этого проект стартует.
Тут я с Вами не согласен. Ряд игровых студий ставит во главе франшизы (игрового продукта разрабатываемого на основе определённой IP) игрового продюсера. Но ряд других студий ставит во главе проекта (продукта) ПМ. Во втором случае именно ПМ нанимает продюсера, который сформирует облик будущего продукта. Именно ПМ нанимает технических руководителей, которые разработают архитектуру продукта и выберут технологии, при использовании которых продукт будет реализован.
Понятно, что ПМ не будет напрямую вмешиваться как в разработку дизайна продукта, так и в разработку технического дизайна. Но у ПМ есть ограничители — сроки, бюджет и тема.
Фокус на управлении задачами. Как мы делаем свою систему управления
Отдел маркетинга решает внедрить новую систему сбора статистики. Предположим, у компании имеются 3 продукта, куда это следует сделать. Соответственно, руководитель отдела маркетинга создаёт у себя 1 задачу:
Статистика-1 — Внедрить систему сбора статистики Ы в продукты компании
и в ней — три подзадачи:
Статистика-1.1 — Внедрить систему сбора статистики Ы в Продукт № 1
Статистика-1.2 — Внедрить систему сбора статистики Ы в Продукт № 2
Статистика-1.3 — Внедрить систему сбора статистики Ы в Продукт № 3
Корневую задачу он назначает на выделенного сотрудника своего отдела, который будет коммуницировать с продуктовыми командами, а подзадачи — на руководителей соответствующих проектов.
Все коммуникации с продуктовыми командами отдел маркетинга желает вести в соответствующих подзадачах. Мы использовали asana — так что обсуждения были доступны всем заинтересованным лицам.
Но вся проблема в том, что у продуктовых команд своя система работы с задачами. То, что для отдела маркетинга выглядит, как задача и три подзадачи, для каждой продуктовой команды выглядит, как проект (ну или мини-проект). Должны быть сформулированы и обсуждены критерии успешного завершения этого проекта, разработаны тесты для проверки критериев, задачи разбиты на подзадачи и распределены между разными специалистами (клиентскими программистами, серверными программистами).
Да, обсуждать условия задачи удобно в маркетинговых подзадачах. Но управлять через них разработкой — нет.
Можно, конечно, в маркетинговых подзадачах обсудить условия, а затем — вынести их в виде отдельных задач для продуктовой команды. Но после этого потеряется связь между маркетологом и отдельными программистами, т.к. программисты будут работать по своим задачам, а маркетолог — не будет иметь доступа к ним (а даже, если и будет, то ему будет неудобно давать ответы во множестве разработческих задач, и он в них запутается).
Жанры и сеттинги мобильных игр — статистика на апрель 2017г
Скрам в реальном мире. Обзор встречи для скрам-мастеров
6) Приводимые примеры либо берутся из других областей (журналистика, конструирование и т.п.), о которых выступающий «не в зуб ногой», либо берутся сильно упрощённые примеры из индустрии разработки ПО, но они сильно примитизированы.
Реальные кейсы НЕ рассматриваются.
Скрам в реальном мире. Обзор встречи для скрам-мастеров
2. Согласно Википедии:
Ссылка
Как видите, нигде не сказано, что KPI предназначены только для измерения производительности, а измерение достижения цели никак не осуществляют. Наоборот, отмечается:
Там же
По-прежнему, различий не вижу.
Скрам в реальном мире. Обзор встречи для скрам-мастеров
Пока что, это не сделано. И всё это выглядит, как обыкновенный «ребрендинг», когда давно известные вещи заменяются другими терминами без изменения сути. Да и связь со скрамом не приведена и, мягко говоря, притянута за уши.
Отсутствуют и примеры из индустрии. Мы ведь обсуждаем процесс разработки софта, а не процесс написания статей.
2. В первой же найденной ссылке отличие OKR от KPI описывается так:
Это как бы не тот ответ, который ожидаешь получить. Такое сравнение уместно в кружке начинающих литераторов, но никак не инженеров.
Скрам в реальном мире. Обзор встречи для скрам-мастеров
2. Прочитал. По-прежнему, не вижу разницы. Можете конкретизировать, в чем она заключается? Хотя бы назвать 2-3 отличия.
3. В приведённой статье и в докладе отсутствуют примеры целей и результатов из индустрии.
Без п.п. 2 и 3 всё излагаемое, к сожалению, не больше, чем набор благих пожеланий и частных оценок.
Скрам в реальном мире. Обзор встречи для скрам-мастеров
2. Планирование, целеполагание и оценка эффективности по ключевым метрикам повышает эффективность работы не только скрам-команд, а и вообще любых команд. В чем тут особенность применения методик Ф. Тейлора и П. Друкера применительно именно к скрам — не раскрыто.
Скрам в реальном мире. Обзор встречи для скрам-мастеров
Скрам в реальном мире. Обзор встречи для скрам-мастеров
Обе мысли правильны, но далеко не новы. Стоило ли повторять их ещё раз или тратить на их изложение аж 25 минут — непонятно. Также неясно, при чём здесь скрам.
Архитектура клиентского приложения (механизмы структуризации)
Архитектура клиентского приложения (механизмы структуризации)
Уровень редактирования поддерживает 2 важные вещи:
1. Архитектуру Документ-Вид (когда с каждым документом связывается один или несколько видов). В простейшем случае, для документа «визуальный эффект» создается окно редактирования этого визуального эффекта.
2. Undo/Redo стек, который поддерживает возможность отмены операции.
Эти две вещи довольно-таки общие для разных редакторов. По этой причине я и предлагаю вынести их в отдельный слой (уровень).
Архитектура клиентского приложения (механизмы структуризации)
Методики проектирования каждого слоя (или в терминах данной статьи — уровня) различаются. Например, на каждом уровне используются свои подходы к выявлению классов.
The Pitch Canvas — шаблон для коротких презентаций
На мой взгляд, в нём не хватает картинок и текст выглядит слишком длинным. Хотя структура презентации, возможно, и правильная.
The Pitch Canvas — шаблон для коротких презентаций
Ну а если писать более серьёзно — то мне, как читателю, было бы интересно:
«Исключить нельзя использовать» — новый метод управления рисками
Относительно «проблемы». Ну и что из того, что посетители фитнес-клуба из разных слоёв общества? Если это сильно мешает, то для состоятельных людей создаются свои фитнес-клубы, куда обычному работяге будет ходить не по карману. А для «работяг» создаются свои бюджетные, «рабоче-крестьянские» фитнес-клубы, посещение которых будет разумным по цене и по обстановке. При развитии рынка нельзя сделать услугу абсолютно для всех. Наоборот, следует выбирать свою целевую группу, под которую и затачивается услуга.
И тут Вы ничего нового не сказали — это азы маркетинга.
Теперь относительно предложенного «решения». Вы в самом деле думаете, что одинаковая форма поможет стереть культурные и коммуникационные различия?
Ну и про то, что это негигиенично — Вам тоже написали.
Обратная сторона Agile — разбирая чужие ошибки
Подробно об обязанностях продюсера видеоигр рассказано в статье на википедии.
Еще более подробно обязанности продюсера изложены во внутренних документах игровых студий.
При разработке бизнес-приложений есть аналогичная роль, которая называется по-другому. Например, в Майкрософт — это program manager (не путать с project manager'ом!). О его обязанностях рассказано здесь и здесь.