Можно не кидаться делать эти мелкие задачи сразу, как только они возникнут, а собрать в «пачку», сделать ТЭО для «пачки» и уже принимать решение на основе дроби Эффективность/Затраты.
В данном случае я не пытаюсь оценить идею с коммерческой точки зрения. У меня просто нет данных, чтобы это оценить. Я пытаюсь понять, на что были потрачены бессонные ночи и для чего понадобилась записывать идеи 24 часа в сутки. Судя по тому, что Вы написали — тут одна идея, причём довольно тривиальная, т.к. уже используется во многих продуктах. О каком креативе идёт речь?
Опять-таки, я не пишу о том, плохая эта идея или хорошая. Я говорю о том, что она также проста, как ход Е2Е4.
Не совсем понимаю, в чем заключается креатив. Шаблоны документов имеются в Word'е, iWork, GoogleDocs и много где ещё. Использовать шаблоны для постов в социальных сетях — это прямой перенос имеющегося решения, как в шахматах ход Е2Е4.
Дело не в том, как Вы организуете доступ к базе данных — через микросервис или посредством слоя доступа к данным, а в том, что Вы понимаете под словом фича (feature). Обычно под feature понимают некоторую пользовательскую функцию, т.е. особенность приложения, которая интересна пользователю. Когда приложение рассматривается в виде набора (или дерева) фич, то при этом осуществляется функциональная декомпозиция приложения с точки зрения пользователя. Но эта декомпозиция никак не совпадает со структурной декомпозицией того же самого приложения, которое осуществляет инженер вне зависимости от того, какая архитектура, какие принципы заложены в основе этой технической декомпозиции: будь то разбиение по слоям, микросервисы, MVC и т.д. и т.п.
Взглядов на одно и тоже приложение может быть несколько. И нужно четко понимать различия между этими взглядами, в том числе, различие между взглядом пользователя и взглядом инженера.
Если пользователь покупает холодильник, то, возможно, ему не надо предлагать микроволновки или стиральные машины, но сопутствующие товары — магнитики на холодильник, поглотители запахов, хлебницы, которые могут быть поставлены на холодильник и т.п. — будут вполне кстати. Даже если это лично Вам не надо, то другим покупателям такие сопутствующие товары будут весьма кстати.
Вся проблема заключается в том, что даже в простых приложениях часто невозможно представить одну фичу одним модулем. Предположим, речь идет о такой простой функции, как добавление нового Клиента в какое-нибудь бизнес-приложение. Такая фича потребует создание новой формы, изменений в слое доступа к данным и в базе данных. Возможно, потребуются небольшие изменения и в слое бизнес-логики.
В приведенном примере одна простая фича затронула сразу 3-4 подсистемы. Более сложные фичи в более сложных приложениях могут затронуть большее количество подсистем, и изменения могут оказаться не такими простыми. Так что рекомендация "1 фича = 1 модуль" — это лишь благое, но нежизнеспособное пожелание.
На заводах концерна Тойота используется Toyota Production System (производственная система Тойота), а вовсе не канбан в том виде, в котором его пытаются поженить с ИТ-отраслью. Использование же общего названия "канбан" ни о какой похожести систем менеджмента не говорит.
Следует также понимать, что Toyota Production System разработана для массового или крупносерийного производства, а разработка программного обеспечения — это даже не мелкосерийное, а штучная разработка (часто на заказ).
Проблема в том, что все эти примеры с автомобильным движением, пробками, командами типа "Газмяс" и прочее оторваны от реальных программных проектов. Серьёзно любую методологию управления проектами можно обсуждать только после того, как она опробована в жизни на реальном проекте.
При таком обсуждении интересуют не общие слова о ценностях и не формальная схема типа "потока работ" — это может быть интересно разве что студентам, а не профессионалам, поучаствовавшим в десятках проектах. Интересна специфика, которая может свидетельствовать как за, так и — главное — против обсуждаемой методологии ведения проектов.
К таким специфичным деталям относятся информация о продукте, сложность проекта, время проекта, размер команды, междисциплинарное взаимодействие (сколько и каких специалистов было задействовано на проекте, как они взаимодействовали). Например, при создании видеоигры в работе над проектом участвуют люди совершенно разных специальностей: программисты, продюсеры, гейм-дизайнеры, моделлеры, аниматоры, 2Д-художники, технические аниматоры, аудиодизайнеры, инженеры по качеству и т.д. и т.п. Специальностей будет больше, чем при создании бизнес-софта. Как построено взаимодействие между этими людьми? Как они находят общий язык между собою? Как методология помогает в этом?
В любом случае, тикеты нужно ранжировать по трудоемкости, например: «простая заявка», «задача» и т.д. Если для простой заявки время выполнения занимает 10-20 минут, то согласен, можно оценивать поштучно.
Что касается багов, то никто баги бесплатно исправлять не будет. Продуктовые компании с отлаженным циклом разработки закладывают на исправление багов от 30 до 50 % времени (от всего цикла разработки). У меня был опыт работы по процессам одной крупной (и известной корпорации). Так там время на исправление багов занимает даже больше времени, отведенного на разработку. А в одном из проектов количество найденных багов приближалось к 30 тысячам.
Аутсорсинговые компании тоже не исправляют баги бесплатно. Стоимость багофикса закладывается в бюджет проекта, а чтобы бюджет не раздувался, тестирование проводится не слишком-то качественно. Ну найдет потом заказчик пару-тройку багов в течение срока гарантии — их поправят. Это копейки по сравнению с объёмом не выявленных багов, которые всплывут уже после того, как гарантия на софт закончится.
После прочтения статьи у меня сложилось впечатление, что идеи, изложенные автором, пришли откуда-то из начала 90-х или даже конца 80-х годов. В конце 80-х модной тенденцией было перевод всех на хозрасчет и самоокупаемость. В начале 90-х годов думали, как бы правильно привязать зарплату к продажам (как бы установить правильный процент с продаж).
Про риски такого подхода, связанные с установкой зарплат для админов, уже правильно заметили. Добавлю свои комментарии по программистам.
Первое, о чем хочется сказать, так это то, что тикеты (запросы, которые необходимо реализовать) имеют разную трудоемкость. Поэтому если уж привязывать зарплату программиста (или бюджет отдела программирования), то нужно привязывать её (его) к трудоёмкости, а не просто к количеству запросов.
Вторая вещь, о которой хочется сказать, заключается в том, что тикет может быть не закрыт в течение одного месяца. Такое случается, если тикет — это не простой баг, а сложная задача, которую тоже требуется реализовать. Конечно, тикет можно разбить на несколько подзадач, но дело в том, что заказчику тикета отдельные реализованные подзадачи не нужны. Ему нужна реализация тикета полностью. Т.е. если оценивать работу отдела программирования извне, то с точки зрения внешнего заказчика задача не реализована, пока она не реализована полностью, и поэтому платить не за что.
Третья вещь — это способность компании обеспечивать надлежащий входной поток тикетов для содержания отдела программирования. Т.е. если компания не сможет загрузить программистов работой, а оплату будет производить только по реализованным тикетам, то весь отдел программирования просто разбежится. Конечно, можно отказаться от такого отдела и обратиться к аутсорсеру. Но практика показывает, что работа с аутсорсером без собственного технического специалиста, который просто банально делает правильную декомпозицию задач, отчасти организует работу аутсорсера, а отчасти — проверяет её, приводит к плохому качеству сделанной работы.
На мой взгляд, первая ошибка — весьма спорная. Предоставить всю необходимую по задаче информацию можно только для простых задач, когда область постановки задачи совпадает с областью её решения. Но чаще ситуация складывается иным образом — когда даже результаты решения задачи не могут быть определены, не говоря уже о требуемых ресурсах. В таких случаях разбивают процесс решения задачи на этапы. Первый этап — определение того, что собственно является результатом решения задачи, т.е. формулируются критерии того, что задача решена, и эти критерии могут быть проверены внешним наблюдателем, например, сотрудником отдела тестирования. Следующий этап — это формулирование алгоритма решения задачи. Затем — перечень необходимых ресурсов (например, списка литературы, которая должна быть проработана). Наконец — решение самой задачи.
К сожалению, статья представляет собой некий сумбур из проблем, с которыми столкнулся Автор, и банальностей. Меня же, как человека имеющего некоторый опыт управления сотрудниками, интересуют и проблемы, и удачные решения. А решения, к сожалению, в статье не перечислены.
Одна из проблем, которая упоминается Автором — это налаживание коммуникаций среди членов удаленной команды. В управлении проектами есть такой процесс — управление коммуникациями. При старте проекта менеджер готовит документ, который называется communication plan. Этот документ перечисляет как, когда и при помощи каких инструментов будет происходить общение между членами команды. Его составными частями являются:
Список контактов
Организационная диаграмма
Группы рассылки
Скайп-конференции
Расписание стендапов, синкапов и других совещаний
Правила работы с электронной почтой и рекомендации по написанию писем
И т.д.
Было бы интересно прочитать в статье подобные технологичные и структурированные описания решений проблем, а не просто сумбурные эмоции о наболевшем.
1. Если сравнить организационную диаграмму на рисунке 1 с организационной диаграммой на рисунке 3, то за исключением названий пары должностей они одинаковые. Конечно, можно Project Manager'а переименовать в Team Lead'а, а Team Lead'а — в Competence Lead'а. Но вряд ли от такого переименования что-то кардинально изменится.
Пойдём дальше…
2. Утверждение о том, что при организации команды, как на рисунке 1, за сроки отвечает только менеджер, а Team Lead и другие члены команды — нет, несколько голословно. Это утверждение должно быть обосновано. Если у Автора в команде именно так, то это не означает, что в других командах точно такая же проблема. У нас за сроки реализации задачи отвечает человек, на которого она назначена. Если он испытывает какие-то технические сложности, то ему обязан помочь Team Lead. Если имеются какие-то организационные сложности (нет доступа к определённому ресурсу, вовремя не заведён аккаунт и т.д. и т.п.), то к делу подключается Project Manager.
3. Утверждение о том, что аналитик (в нашем случае — продюсер) и программист будут играть в футбол, переназначая задачу друг на друга тоже ни чем не мотивировано. У нас дизайн-документы с описанием требований должны быть подготовлены до начала production или до начала работы над определённым майлстоуном. Если дизайн фичи не готов, то она просто не пойдёт в production. Даже если вдруг потребуется добавить какую-нибудь фичу в середине работы над майлстоуном, то существует такой процесс, как ревью дизайн-документа. Перед ревью дизайн документ рассылается всем заинтересованным лицам так, что они имеют время его изучить. Во время ревью продюсер рассказывает о фиче, а инженеры задают вопросы и высказывают свои замечания. По результатам ревью продюсер вносит в дизайн-документ изменения. Кроме того, наличие замечаний или вопросов не является основанием для приостановки работы над фичей. Она идёт в production, просто продюсер параллельно вносит в дизайн-документ изменения, о которых договорились во время ревью.
4. Аналогично утверждение о футболе багов между тестером и инженером не выдерживает критики. Количества открытых и закрытых багов регулярно мониторятся менеджером проекта. Существуют метрики, позволяющие оценить качество работы инженера и инженера по тестированию. Среди них для оценки качества работы программиста на этапе bugfixing'а — количество исправленных багов в неделю и количество повторно переоткрытых багов (не должно быть больше 4%). Качество работы инженера по качеству оценивается с помощью сравнения количества найденных новых багов с количеством багов, которое планировалось найти к данной дате, а также — с помощью количества возвратов бага со стороны инженера (таким образом проверяется, насколько качественно сделано описание бага и steps to reproduce).
5. В целом, организационная диаграмма и название должностей не дают полного представления о качестве работы команды. Если нужно повысить качество работы команды, то следует начинать описание с зон ответственности, процессов и метрик. Простое переименование должностей ни к чему не ведёт.
Поясню свою ремарку про аутсорс. Исходя из моего 19-летнего опыта работы, аутсорсер не обладает методологиями управления проектами. В аутсорсинговых компаниях проекты либо ведутся как попало, либо на проекте устанавливаются процессы заказчика. Если заказчик — продуктовая компания с богатым опытом разработки и выпуска ИТ-продуктов, то процессы на проекте поставлены хорошо. Если заказчик иной, то процессы не выстроены, и разработка ведётся как попало. Все же разговоры про «гибкие методологии» в данном случае ведутся с целью оправдания такого проектного бардака и нежеланием ставить процессы разработки.
Если Вы понимаете под «водопадом» последовательность Концепция -> Дизайн -> Технический дизайн -> Реализация -> Тестирование и исправление ошибок, то мой ответ — «да». Хотя мой заказчик считает, что применяет «гибкие методологии». Что касается меня, то я считаю такую последовательность этапов обычным инженерным подходом.
В своё время в ТВ-рекламе стиральный порошок «Тайд» сравнивали с «Обычным стиральным порошком». Что это за «зверь» такой — было непонятно, кроме одного — «Обычный стиральный порошок» обладает всеми мыслимыми и немыслимыми недостатками.
Прочитав эту статью, я понял, что автор ставит «Водопад» (а по мне так — нормальный процесс разработки ПО) на место «Обычного стирального порошка» и приписывает ему всевозможные недостатки. При этом, судя по качеству аргументации, возникает сомнение, что автор когда-либо работал по т.н. «водопаду».
Если говорить о конкретных неточностях в статье, то вот это утверждение:
«В тяжеловесных методологиях аналитик похож на слабопроницаемую стену между командой разработчиков и представителями заказчика/бизнеса»
— является полностью недостоверным и непонятно, на основе каких данных автор делает такой вывод.
Следующее за ним утверждение:
«Чтобы сделать хороший продукт, приходится тратить кучу сил на «ковыряние дырок» в этой стене»
— тоже не является истиной.
А вот это утверждение:
«Кроме того, ужасно высоки риски, связанные с ошибками аналитика. Команде разработчиков при этом отводится роль второго плана»
— справедливо для любой методологии разработки ПО, т.к. неправильное описание бизнес-процесса может привести к существенной переделки бизнес-приложения.
Общая рекомендация автору — поработать в продуктовой компании с поставленным процессом разработки ПО, т.е. приобрести реальный опыт в т.н. «водопаде», а потом уже сравнивать хаос аутсорсинговой разработки, выдаваемый почему-то за аджайл, с качественным процессом.
По статье — имхо, слишком мало конкретики. Мало примеров, мало погружений в задачи.
Опять-таки, я не пишу о том, плохая эта идея или хорошая. Я говорю о том, что она также проста, как ход Е2Е4.
Взглядов на одно и тоже приложение может быть несколько. И нужно четко понимать различия между этими взглядами, в том числе, различие между взглядом пользователя и взглядом инженера.
В приведенном примере одна простая фича затронула сразу 3-4 подсистемы. Более сложные фичи в более сложных приложениях могут затронуть большее количество подсистем, и изменения могут оказаться не такими простыми. Так что рекомендация "1 фича = 1 модуль" — это лишь благое, но нежизнеспособное пожелание.
Не с десятью проектами, а с десятками завершённых проектов. На текущий момент это 40 проектов.
Следует также понимать, что Toyota Production System разработана для массового или крупносерийного производства, а разработка программного обеспечения — это даже не мелкосерийное, а штучная разработка (часто на заказ).
При таком обсуждении интересуют не общие слова о ценностях и не формальная схема типа "потока работ" — это может быть интересно разве что студентам, а не профессионалам, поучаствовавшим в десятках проектах. Интересна специфика, которая может свидетельствовать как за, так и — главное — против обсуждаемой методологии ведения проектов.
К таким специфичным деталям относятся информация о продукте, сложность проекта, время проекта, размер команды, междисциплинарное взаимодействие (сколько и каких специалистов было задействовано на проекте, как они взаимодействовали). Например, при создании видеоигры в работе над проектом участвуют люди совершенно разных специальностей: программисты, продюсеры, гейм-дизайнеры, моделлеры, аниматоры, 2Д-художники, технические аниматоры, аудиодизайнеры, инженеры по качеству и т.д. и т.п. Специальностей будет больше, чем при создании бизнес-софта. Как построено взаимодействие между этими людьми? Как они находят общий язык между собою? Как методология помогает в этом?
А примеры с дорожным движением — это для детей.
Что касается багов, то никто баги бесплатно исправлять не будет. Продуктовые компании с отлаженным циклом разработки закладывают на исправление багов от 30 до 50 % времени (от всего цикла разработки). У меня был опыт работы по процессам одной крупной (и известной корпорации). Так там время на исправление багов занимает даже больше времени, отведенного на разработку. А в одном из проектов количество найденных багов приближалось к 30 тысячам.
Аутсорсинговые компании тоже не исправляют баги бесплатно. Стоимость багофикса закладывается в бюджет проекта, а чтобы бюджет не раздувался, тестирование проводится не слишком-то качественно. Ну найдет потом заказчик пару-тройку багов в течение срока гарантии — их поправят. Это копейки по сравнению с объёмом не выявленных багов, которые всплывут уже после того, как гарантия на софт закончится.
Про риски такого подхода, связанные с установкой зарплат для админов, уже правильно заметили. Добавлю свои комментарии по программистам.
Первое, о чем хочется сказать, так это то, что тикеты (запросы, которые необходимо реализовать) имеют разную трудоемкость. Поэтому если уж привязывать зарплату программиста (или бюджет отдела программирования), то нужно привязывать её (его) к трудоёмкости, а не просто к количеству запросов.
Вторая вещь, о которой хочется сказать, заключается в том, что тикет может быть не закрыт в течение одного месяца. Такое случается, если тикет — это не простой баг, а сложная задача, которую тоже требуется реализовать. Конечно, тикет можно разбить на несколько подзадач, но дело в том, что заказчику тикета отдельные реализованные подзадачи не нужны. Ему нужна реализация тикета полностью. Т.е. если оценивать работу отдела программирования извне, то с точки зрения внешнего заказчика задача не реализована, пока она не реализована полностью, и поэтому платить не за что.
Третья вещь — это способность компании обеспечивать надлежащий входной поток тикетов для содержания отдела программирования. Т.е. если компания не сможет загрузить программистов работой, а оплату будет производить только по реализованным тикетам, то весь отдел программирования просто разбежится. Конечно, можно отказаться от такого отдела и обратиться к аутсорсеру. Но практика показывает, что работа с аутсорсером без собственного технического специалиста, который просто банально делает правильную декомпозицию задач, отчасти организует работу аутсорсера, а отчасти — проверяет её, приводит к плохому качеству сделанной работы.
оптировать.Одна из проблем, которая упоминается Автором — это налаживание коммуникаций среди членов удаленной команды. В управлении проектами есть такой процесс — управление коммуникациями. При старте проекта менеджер готовит документ, который называется communication plan. Этот документ перечисляет как, когда и при помощи каких инструментов будет происходить общение между членами команды. Его составными частями являются:
Было бы интересно прочитать в статье подобные технологичные и структурированные описания решений проблем, а не просто сумбурные эмоции о наболевшем.
Пойдём дальше…
2. Утверждение о том, что при организации команды, как на рисунке 1, за сроки отвечает только менеджер, а Team Lead и другие члены команды — нет, несколько голословно. Это утверждение должно быть обосновано. Если у Автора в команде именно так, то это не означает, что в других командах точно такая же проблема. У нас за сроки реализации задачи отвечает человек, на которого она назначена. Если он испытывает какие-то технические сложности, то ему обязан помочь Team Lead. Если имеются какие-то организационные сложности (нет доступа к определённому ресурсу, вовремя не заведён аккаунт и т.д. и т.п.), то к делу подключается Project Manager.
3. Утверждение о том, что аналитик (в нашем случае — продюсер) и программист будут играть в футбол, переназначая задачу друг на друга тоже ни чем не мотивировано. У нас дизайн-документы с описанием требований должны быть подготовлены до начала production или до начала работы над определённым майлстоуном. Если дизайн фичи не готов, то она просто не пойдёт в production. Даже если вдруг потребуется добавить какую-нибудь фичу в середине работы над майлстоуном, то существует такой процесс, как ревью дизайн-документа. Перед ревью дизайн документ рассылается всем заинтересованным лицам так, что они имеют время его изучить. Во время ревью продюсер рассказывает о фиче, а инженеры задают вопросы и высказывают свои замечания. По результатам ревью продюсер вносит в дизайн-документ изменения. Кроме того, наличие замечаний или вопросов не является основанием для приостановки работы над фичей. Она идёт в production, просто продюсер параллельно вносит в дизайн-документ изменения, о которых договорились во время ревью.
4. Аналогично утверждение о футболе багов между тестером и инженером не выдерживает критики. Количества открытых и закрытых багов регулярно мониторятся менеджером проекта. Существуют метрики, позволяющие оценить качество работы инженера и инженера по тестированию. Среди них для оценки качества работы программиста на этапе bugfixing'а — количество исправленных багов в неделю и количество повторно переоткрытых багов (не должно быть больше 4%). Качество работы инженера по качеству оценивается с помощью сравнения количества найденных новых багов с количеством багов, которое планировалось найти к данной дате, а также — с помощью количества возвратов бага со стороны инженера (таким образом проверяется, насколько качественно сделано описание бага и steps to reproduce).
5. В целом, организационная диаграмма и название должностей не дают полного представления о качестве работы команды. Если нужно повысить качество работы команды, то следует начинать описание с зон ответственности, процессов и метрик. Простое переименование должностей ни к чему не ведёт.
Что бы хотелось увидеть:
А пока нет конкретики, то и обсуждать, к сожалению, нечего.
Если Вы понимаете под «водопадом» последовательность Концепция -> Дизайн -> Технический дизайн -> Реализация -> Тестирование и исправление ошибок, то мой ответ — «да». Хотя мой заказчик считает, что применяет «гибкие методологии». Что касается меня, то я считаю такую последовательность этапов обычным инженерным подходом.
Прочитав эту статью, я понял, что автор ставит «Водопад» (а по мне так — нормальный процесс разработки ПО) на место «Обычного стирального порошка» и приписывает ему всевозможные недостатки. При этом, судя по качеству аргументации, возникает сомнение, что автор когда-либо работал по т.н. «водопаду».
Если говорить о конкретных неточностях в статье, то вот это утверждение:
«В тяжеловесных методологиях аналитик похож на слабопроницаемую стену между командой разработчиков и представителями заказчика/бизнеса»
— является полностью недостоверным и непонятно, на основе каких данных автор делает такой вывод.
Следующее за ним утверждение:
«Чтобы сделать хороший продукт, приходится тратить кучу сил на «ковыряние дырок» в этой стене»
— тоже не является истиной.
А вот это утверждение:
«Кроме того, ужасно высоки риски, связанные с ошибками аналитика. Команде разработчиков при этом отводится роль второго плана»
— справедливо для любой методологии разработки ПО, т.к. неправильное описание бизнес-процесса может привести к существенной переделки бизнес-приложения.
Общая рекомендация автору — поработать в продуктовой компании с поставленным процессом разработки ПО, т.е. приобрести реальный опыт в т.н. «водопаде», а потом уже сравнивать хаос аутсорсинговой разработки, выдаваемый почему-то за аджайл, с качественным процессом.