Вы описываете один конкретный случай из множества возможных.
Я привёл лишь пример, при котором предлагаемая Вами схема коммуникации очень быстро будет перегружена.
Соответственно в этих условиях часто заказчик не является грамотным технарем, продуктовым менеджером и так далее.
Я с этим не спорю. Я лишь показываю, что в качестве Заказчика может выступать коллектив людей, и эти люди могут иметь разную специализацию.
У меня буквально на днях такой случай был — программист со стороны заказчика внедряя наш код, не спрашивал непонятное — а делал по своему разумению, чем создал сложности, хотя имел все возможности спросить. Даже языкового барьера не было.
Этот пример показывает, насколько важно налаживать коммуникацию между представителями Заказчика и представителями Исполнителя. Входе реализации проекта коммуникациями нужно управлять, а не замыкать их на одного или нескольких менеджеров. Нужно устанавливать горизонтальные связи «специалист — специалист».
И документация мертва, а древо жизни зеленеет.
Если документация выполнила свою задачу, и в неё больше никто не заглядывает, то её бесполезно менять. Другой вопрос — должны последовать изменения, которые затрагивают работу других людей. Например, изменены условия задачи для программиста (или поставлена другая задача), а также — должны быть обновлены тест-кейсы. Последовательность и каналы информирования других заинтересованных лиц должны быть предусмотрены в плане коммуникаций.
Риски справедливы, но при описанном методе имхо их еще больше.
Распределённая работа позволяет убрать эффект «бутылочного горлышка», но требует управления коммуникациями и синхронизацией между членами одной команды и разными командами.
Представьте себе, что Вы участвуете в проекте, работу над которым ведут одновременно 100 человек, распределённых по разным командам, а команды находятся в разных городах и на разных континентах. Насколько тогда хватит одного менеджера-коммуникатора?
Во-первых это не их работа.
Тут я с Вами не согласен. Наоборот, считаю, что если программист работает над реализацией определённой фичи, то ему нужно коммуницировать с продюсером, который эту фичу придумал и описал. Не все аспекты фичи можно заранее прописать в документе. Иногда возникают вопросы. И если вопрос возник — самое время обратиться к автору фичи. Если это сделать через менеджера, то он, скорее всего, пропустит мимо ушей определённые тонкости, т.к. не он реализует фичу и не он является её продюсером.
Также если смежную фичу реализует другой программист из другой команды, то первый программист должен обязательно с ним общаться, т.к. есть пересекающиеся места в коде, в архитектуре. Технические решения нужно согласовать.
В-третьих они тогда должны делиться всей информацией с командой, чтобы все были в курсе о принятых решениях, изменениях.
Синхронизация осуществляется довольно просто. Программист обращается к продюсеру с каким-нибудь вопросом по фиче, продюсер даёт ему ответ, а затем — если необходимо — вносит изменения в документацию по фиче и/или в условия задачи.
Как промежуточное решение — все общаются в одном чате с заказчиком, но контроль, фасилитация и ответственность за это — все равно на менеджере.
Следует различать менеджера проекта и продуктового менеджера. Менеджер проекта не вмешивается в вопросы дизайна фичи и в вопросы технической реализации. Его интересует скоуп работ, сроки, ресурсы. А менеджер продукта — да, как раз занимается фичами. Если требуется продуктовый менеджер на стороне исполнителя, то согласен — вопросы к продюсеру проекта со стороны заказчика можно задавать через него.
Второе — быть единым контактным лицом для всех. Вся информация должна проходить через него, иначе сразу начнется бардак. Заказчик договорится с отдельным разработчиком, или предъявит ему баги, тот никому не скажет, баги касаются и других и пошло-поехало.
Если ПМ станет единым контактным лицом для всех, то он быстро превратится в «бутылочное горлышко», в результате чего весь процесс разработки застопорится, т.к. все будут ждать его решения, а он хронически будет не успевать.
Кроме того, он ещё рискует превратиться в «испорченный телефон», т.к. вольно или невольно будет искажать детали задачи. Наоборот, лучше, когда по конкретной задаче разработчик коммуницирует с представителем заказчика напрямую, а в случае необходимости выполнения отдельной задачи, которая не учитывалась при оценке проекта, её нужно вносить в систему контроля задач и помещать в бэклог. Новая задача только тогда поступает на выполнение, когда она согласована ПМ с соответствующим представителем заказчика.
Он начинает свою работу тогда, когда цель продукта уже ясна. Продукт имеет верхнеуровневые требования и некоторые рамки.
Согласен. Возьмём для примера издателя видеоигр, у которого во владении есть несколько игровых студий. Для чего нужен пример? Поясню ниже.
Издатель формирует свою линейку игр. Он решает, что через год или полтора в апреле месяце должна быть выпущена игра по определённой тематике. Таким образом, определяются сроки выпуска игры, длительность её разработки, тематика и, вероятнее всего, есть какие-то прикидки по бюджету. После этого проект стартует.
Но он не решает практически ничего. Да он может влиять на проект через операционку, но не решать. Если он вдруг начинает решать что-то, то это уже не ПМ. Точнее не проэктный-менеджер.
Тут я с Вами не согласен. Ряд игровых студий ставит во главе франшизы (игрового продукта разрабатываемого на основе определённой IP) игрового продюсера. Но ряд других студий ставит во главе проекта (продукта) ПМ. Во втором случае именно ПМ нанимает продюсера, который сформирует облик будущего продукта. Именно ПМ нанимает технических руководителей, которые разработают архитектуру продукта и выберут технологии, при использовании которых продукт будет реализован.
Понятно, что ПМ не будет напрямую вмешиваться как в разработку дизайна продукта, так и в разработку технического дизайна. Но у ПМ есть ограничители — сроки, бюджет и тема.
На мой взгляд, главная проблема всех таск-трекинг систем находится на стыке взаимодействия отделов. Приведу пример.
Отдел маркетинга решает внедрить новую систему сбора статистики. Предположим, у компании имеются 3 продукта, куда это следует сделать. Соответственно, руководитель отдела маркетинга создаёт у себя 1 задачу:
Статистика-1 — Внедрить систему сбора статистики Ы в продукты компании
и в ней — три подзадачи:
Статистика-1.1 — Внедрить систему сбора статистики Ы в Продукт № 1
Статистика-1.2 — Внедрить систему сбора статистики Ы в Продукт № 2
Статистика-1.3 — Внедрить систему сбора статистики Ы в Продукт № 3
Корневую задачу он назначает на выделенного сотрудника своего отдела, который будет коммуницировать с продуктовыми командами, а подзадачи — на руководителей соответствующих проектов.
Все коммуникации с продуктовыми командами отдел маркетинга желает вести в соответствующих подзадачах. Мы использовали asana — так что обсуждения были доступны всем заинтересованным лицам.
Но вся проблема в том, что у продуктовых команд своя система работы с задачами. То, что для отдела маркетинга выглядит, как задача и три подзадачи, для каждой продуктовой команды выглядит, как проект (ну или мини-проект). Должны быть сформулированы и обсуждены критерии успешного завершения этого проекта, разработаны тесты для проверки критериев, задачи разбиты на подзадачи и распределены между разными специалистами (клиентскими программистами, серверными программистами).
Да, обсуждать условия задачи удобно в маркетинговых подзадачах. Но управлять через них разработкой — нет.
Можно, конечно, в маркетинговых подзадачах обсудить условия, а затем — вынести их в виде отдельных задач для продуктовой команды. Но после этого потеряется связь между маркетологом и отдельными программистами, т.к. программисты будут работать по своим задачам, а маркетолог — не будет иметь доступа к ним (а даже, если и будет, то ему будет неудобно давать ответы во множестве разработческих задач, и он в них запутается).
6) Приводимые примеры либо берутся из других областей (журналистика, конструирование и т.п.), о которых выступающий «не в зуб ногой», либо берутся сильно упрощённые примеры из индустрии разработки ПО, но они сильно примитизированы.
Ключевые показатели эффективности (англ. Key Performance Indicators, KPI) — показатели деятельности подразделения (предприятия), которые помогают организации в достижении стратегических и тактических (операционных) целей. Использование ключевых показателей эффективности даёт организации возможность оценить своё состояние и помочь в оценке реализации стратегии.
Как видите, нигде не сказано, что KPI предназначены только для измерения производительности, а измерение достижения цели никак не осуществляют. Наоборот, отмечается:
По стандарту, результативность — это степень достижения запланированных результатов (способность компании ориентироваться на результат), а эффективность — соотношение между достигнутыми результатами и затраченными ресурсами (способность компании к реализации своих целей и планов с заданным качественным уровнем, выраженным определёнными требованиями – временем, затратами, степенью достижения цели). Слово performance объединяет в себе и результативность, и эффективность. Таким образом, правильным переводом термина KPI будет «ключевой показатель результата деятельности», так как результат деятельности содержит в себе и степень достижения, и затраты на получение результата.
1. А при чём здесь Google, если мы обсуждаем Ваши статью и доклад? Из них не ясно, чем отличается OKR от методики Питера Друкера, предложенной в 1954-ом году. Если Вы предлагаете иной подход, то, наверное, следует описать его отличия и преимущества.
Пока что, это не сделано. И всё это выглядит, как обыкновенный «ребрендинг», когда давно известные вещи заменяются другими терминами без изменения сути. Да и связь со скрамом не приведена и, мягко говоря, притянута за уши.
Отсутствуют и примеры из индустрии. Мы ведь обсуждаем процесс разработки софта, а не процесс написания статей.
2. В первой же найденной ссылке отличие OKR от KPI описывается так:
Comparing KPIs to OKRs is kind of like comparing apples to apple pies.
Это как бы не тот ответ, который ожидаешь получить. Такое сравнение уместно в кружке начинающих литераторов, но никак не инженеров.
1. OKR — это просто новая аббревиатура management by objectives, предложенного Питером Друкером в 1954 году. Хотя подозреваю, что что-то было сделано еще Фредериком Тейлором.Во всяком случае, понятия «цель», «метрика» и «ключевой показатель качества» были известны ещё до основания компании Google (при всём моём уважении к этой компании).
2. Планирование, целеполагание и оценка эффективности по ключевым метрикам повышает эффективность работы не только скрам-команд, а и вообще любых команд. В чем тут особенность применения методик Ф. Тейлора и П. Друкера применительно именно к скрам — не раскрыто.
Прослушал первый доклад. Если резюмировать, то суть доклада можно свести к следующим двум тезисам:
Компания должна ставить цели.
У каждой цели должны быть некие измеряемые критерии, показывающие то, что цель достигнута.
Обе мысли правильны, но далеко не новы. Стоило ли повторять их ещё раз или тратить на их изложение аж 25 минут — непонятно. Также неясно, при чём здесь скрам.
Мне кажется, что при проектировании не нужно сразу искать оптимальную декомпозицию системы на слои. Нужно сделать хоть какое-то разбиение. Это будет первым шагом к разработке структуры. Затем, анализируя дополнительные функции системы, Вам неприменно потребуется решить, к какому слою абстракции их отнести. Нужно понять, какая подсистема будет отвечать за реализацию каждой конкретной функции и где она будет находиться. Возможными ответами на эти вопросы будут: разбиение функций на подфункции, делегирование их разным подсистемам, размещение этих подсистем на разных системных уровнях и, возможно, создание дополнительных системных уровней.
Уровень редактирования поддерживает 2 важные вещи:
1. Архитектуру Документ-Вид (когда с каждым документом связывается один или несколько видов). В простейшем случае, для документа «визуальный эффект» создается окно редактирования этого визуального эффекта.
2. Undo/Redo стек, который поддерживает возможность отмены операции.
Эти две вещи довольно-таки общие для разных редакторов. По этой причине я и предлагаю вынести их в отдельный слой (уровень).
Статья описывает лишь небольшую часть подхода к проектированию клиентских приложений. Если использовать этот подход, то некоторые риски, связанные с тем, что непонятно, какая должна быть архитектура, какого дизайна следует придерживаться и т.д., просто уходят. Процесс разработки преобразуется в последовательность этапов (не только в управленческом смысле, но и в техническом), которые имеют свои конкретные результаты и которые просто нужно выполнить.
Методики проектирования каждого слоя (или в терминах данной статьи — уровня) различаются. Например, на каждом уровне используются свои подходы к выявлению классов.
В Вашей статье 7 абзацев. Из них, на мой взгляд, важными являются первый абзац, т.к. содержит описание проблемы, и ссылка на шаблон презентации. Остальные абзацы можно было бы и опустить.
Ну а если писать более серьёзно — то мне, как читателю, было бы интересно:
либо узнать изложение шаблона Вашими словами (как это понимаете Вы);
либо узнать, как Вы использовали предложенный шаблон для создания Ваших презентаций (практика применения шаблона)
Вы сами придумали «проблему» и сами же предложили «решение».
Относительно «проблемы». Ну и что из того, что посетители фитнес-клуба из разных слоёв общества? Если это сильно мешает, то для состоятельных людей создаются свои фитнес-клубы, куда обычному работяге будет ходить не по карману. А для «работяг» создаются свои бюджетные, «рабоче-крестьянские» фитнес-клубы, посещение которых будет разумным по цене и по обстановке. При развитии рынка нельзя сделать услугу абсолютно для всех. Наоборот, следует выбирать свою целевую группу, под которую и затачивается услуга.
И тут Вы ничего нового не сказали — это азы маркетинга.
Теперь относительно предложенного «решения». Вы в самом деле думаете, что одинаковая форма поможет стереть культурные и коммуникационные различия?
Ну и про то, что это негигиенично — Вам тоже написали.
Впервые термин продюсер применительно к разработке видеоигр использовал Трип Хоукинс, основатель Electronic Arts, в 1982 году.
Подробно об обязанностях продюсера видеоигр рассказано в статье на википедии.
Еще более подробно обязанности продюсера изложены во внутренних документах игровых студий.
При разработке бизнес-приложений есть аналогичная роль, которая называется по-другому. Например, в Майкрософт — это program manager (не путать с project manager'ом!). О его обязанностях рассказано здесь и здесь.
Я привёл лишь пример, при котором предлагаемая Вами схема коммуникации очень быстро будет перегружена.
Я с этим не спорю. Я лишь показываю, что в качестве Заказчика может выступать коллектив людей, и эти люди могут иметь разную специализацию.
Этот пример показывает, насколько важно налаживать коммуникацию между представителями Заказчика и представителями Исполнителя. Входе реализации проекта коммуникациями нужно управлять, а не замыкать их на одного или нескольких менеджеров. Нужно устанавливать горизонтальные связи «специалист — специалист».
Если документация выполнила свою задачу, и в неё больше никто не заглядывает, то её бесполезно менять. Другой вопрос — должны последовать изменения, которые затрагивают работу других людей. Например, изменены условия задачи для программиста (или поставлена другая задача), а также — должны быть обновлены тест-кейсы. Последовательность и каналы информирования других заинтересованных лиц должны быть предусмотрены в плане коммуникаций.
Распределённая работа позволяет убрать эффект «бутылочного горлышка», но требует управления коммуникациями и синхронизацией между членами одной команды и разными командами.
Представьте себе, что Вы участвуете в проекте, работу над которым ведут одновременно 100 человек, распределённых по разным командам, а команды находятся в разных городах и на разных континентах. Насколько тогда хватит одного менеджера-коммуникатора?
Тут я с Вами не согласен. Наоборот, считаю, что если программист работает над реализацией определённой фичи, то ему нужно коммуницировать с продюсером, который эту фичу придумал и описал. Не все аспекты фичи можно заранее прописать в документе. Иногда возникают вопросы. И если вопрос возник — самое время обратиться к автору фичи. Если это сделать через менеджера, то он, скорее всего, пропустит мимо ушей определённые тонкости, т.к. не он реализует фичу и не он является её продюсером.
Также если смежную фичу реализует другой программист из другой команды, то первый программист должен обязательно с ним общаться, т.к. есть пересекающиеся места в коде, в архитектуре. Технические решения нужно согласовать.
Синхронизация осуществляется довольно просто. Программист обращается к продюсеру с каким-нибудь вопросом по фиче, продюсер даёт ему ответ, а затем — если необходимо — вносит изменения в документацию по фиче и/или в условия задачи.
Следует различать менеджера проекта и продуктового менеджера. Менеджер проекта не вмешивается в вопросы дизайна фичи и в вопросы технической реализации. Его интересует скоуп работ, сроки, ресурсы. А менеджер продукта — да, как раз занимается фичами. Если требуется продуктовый менеджер на стороне исполнителя, то согласен — вопросы к продюсеру проекта со стороны заказчика можно задавать через него.
Если ПМ станет единым контактным лицом для всех, то он быстро превратится в «бутылочное горлышко», в результате чего весь процесс разработки застопорится, т.к. все будут ждать его решения, а он хронически будет не успевать.
Кроме того, он ещё рискует превратиться в «испорченный телефон», т.к. вольно или невольно будет искажать детали задачи. Наоборот, лучше, когда по конкретной задаче разработчик коммуницирует с представителем заказчика напрямую, а в случае необходимости выполнения отдельной задачи, которая не учитывалась при оценке проекта, её нужно вносить в систему контроля задач и помещать в бэклог. Новая задача только тогда поступает на выполнение, когда она согласована ПМ с соответствующим представителем заказчика.
Согласен. Возьмём для примера издателя видеоигр, у которого во владении есть несколько игровых студий. Для чего нужен пример? Поясню ниже.
Издатель формирует свою линейку игр. Он решает, что через год или полтора в апреле месяце должна быть выпущена игра по определённой тематике. Таким образом, определяются сроки выпуска игры, длительность её разработки, тематика и, вероятнее всего, есть какие-то прикидки по бюджету. После этого проект стартует.
Тут я с Вами не согласен. Ряд игровых студий ставит во главе франшизы (игрового продукта разрабатываемого на основе определённой IP) игрового продюсера. Но ряд других студий ставит во главе проекта (продукта) ПМ. Во втором случае именно ПМ нанимает продюсера, который сформирует облик будущего продукта. Именно ПМ нанимает технических руководителей, которые разработают архитектуру продукта и выберут технологии, при использовании которых продукт будет реализован.
Понятно, что ПМ не будет напрямую вмешиваться как в разработку дизайна продукта, так и в разработку технического дизайна. Но у ПМ есть ограничители — сроки, бюджет и тема.
Отдел маркетинга решает внедрить новую систему сбора статистики. Предположим, у компании имеются 3 продукта, куда это следует сделать. Соответственно, руководитель отдела маркетинга создаёт у себя 1 задачу:
Статистика-1 — Внедрить систему сбора статистики Ы в продукты компании
и в ней — три подзадачи:
Статистика-1.1 — Внедрить систему сбора статистики Ы в Продукт № 1
Статистика-1.2 — Внедрить систему сбора статистики Ы в Продукт № 2
Статистика-1.3 — Внедрить систему сбора статистики Ы в Продукт № 3
Корневую задачу он назначает на выделенного сотрудника своего отдела, который будет коммуницировать с продуктовыми командами, а подзадачи — на руководителей соответствующих проектов.
Все коммуникации с продуктовыми командами отдел маркетинга желает вести в соответствующих подзадачах. Мы использовали asana — так что обсуждения были доступны всем заинтересованным лицам.
Но вся проблема в том, что у продуктовых команд своя система работы с задачами. То, что для отдела маркетинга выглядит, как задача и три подзадачи, для каждой продуктовой команды выглядит, как проект (ну или мини-проект). Должны быть сформулированы и обсуждены критерии успешного завершения этого проекта, разработаны тесты для проверки критериев, задачи разбиты на подзадачи и распределены между разными специалистами (клиентскими программистами, серверными программистами).
Да, обсуждать условия задачи удобно в маркетинговых подзадачах. Но управлять через них разработкой — нет.
Можно, конечно, в маркетинговых подзадачах обсудить условия, а затем — вынести их в виде отдельных задач для продуктовой команды. Но после этого потеряется связь между маркетологом и отдельными программистами, т.к. программисты будут работать по своим задачам, а маркетолог — не будет иметь доступа к ним (а даже, если и будет, то ему будет неудобно давать ответы во множестве разработческих задач, и он в них запутается).
6) Приводимые примеры либо берутся из других областей (журналистика, конструирование и т.п.), о которых выступающий «не в зуб ногой», либо берутся сильно упрощённые примеры из индустрии разработки ПО, но они сильно примитизированы.
Реальные кейсы НЕ рассматриваются.
2. Согласно Википедии:
Ссылка
Как видите, нигде не сказано, что KPI предназначены только для измерения производительности, а измерение достижения цели никак не осуществляют. Наоборот, отмечается:
Там же
По-прежнему, различий не вижу.
Пока что, это не сделано. И всё это выглядит, как обыкновенный «ребрендинг», когда давно известные вещи заменяются другими терминами без изменения сути. Да и связь со скрамом не приведена и, мягко говоря, притянута за уши.
Отсутствуют и примеры из индустрии. Мы ведь обсуждаем процесс разработки софта, а не процесс написания статей.
2. В первой же найденной ссылке отличие OKR от KPI описывается так:
Это как бы не тот ответ, который ожидаешь получить. Такое сравнение уместно в кружке начинающих литераторов, но никак не инженеров.
2. Прочитал. По-прежнему, не вижу разницы. Можете конкретизировать, в чем она заключается? Хотя бы назвать 2-3 отличия.
3. В приведённой статье и в докладе отсутствуют примеры целей и результатов из индустрии.
Без п.п. 2 и 3 всё излагаемое, к сожалению, не больше, чем набор благих пожеланий и частных оценок.
2. Планирование, целеполагание и оценка эффективности по ключевым метрикам повышает эффективность работы не только скрам-команд, а и вообще любых команд. В чем тут особенность применения методик Ф. Тейлора и П. Друкера применительно именно к скрам — не раскрыто.
Обе мысли правильны, но далеко не новы. Стоило ли повторять их ещё раз или тратить на их изложение аж 25 минут — непонятно. Также неясно, при чём здесь скрам.
Уровень редактирования поддерживает 2 важные вещи:
1. Архитектуру Документ-Вид (когда с каждым документом связывается один или несколько видов). В простейшем случае, для документа «визуальный эффект» создается окно редактирования этого визуального эффекта.
2. Undo/Redo стек, который поддерживает возможность отмены операции.
Эти две вещи довольно-таки общие для разных редакторов. По этой причине я и предлагаю вынести их в отдельный слой (уровень).
Методики проектирования каждого слоя (или в терминах данной статьи — уровня) различаются. Например, на каждом уровне используются свои подходы к выявлению классов.
На мой взгляд, в нём не хватает картинок и текст выглядит слишком длинным. Хотя структура презентации, возможно, и правильная.
Ну а если писать более серьёзно — то мне, как читателю, было бы интересно:
Относительно «проблемы». Ну и что из того, что посетители фитнес-клуба из разных слоёв общества? Если это сильно мешает, то для состоятельных людей создаются свои фитнес-клубы, куда обычному работяге будет ходить не по карману. А для «работяг» создаются свои бюджетные, «рабоче-крестьянские» фитнес-клубы, посещение которых будет разумным по цене и по обстановке. При развитии рынка нельзя сделать услугу абсолютно для всех. Наоборот, следует выбирать свою целевую группу, под которую и затачивается услуга.
И тут Вы ничего нового не сказали — это азы маркетинга.
Теперь относительно предложенного «решения». Вы в самом деле думаете, что одинаковая форма поможет стереть культурные и коммуникационные различия?
Ну и про то, что это негигиенично — Вам тоже написали.
Подробно об обязанностях продюсера видеоигр рассказано в статье на википедии.
Еще более подробно обязанности продюсера изложены во внутренних документах игровых студий.
При разработке бизнес-приложений есть аналогичная роль, которая называется по-другому. Например, в Майкрософт — это program manager (не путать с project manager'ом!). О его обязанностях рассказано здесь и здесь.