Agile *

Несколько картинок, полезных для понимания и объяснения ключевых идей в управлении продуктами

Говорят, одна картинка стоит тысячи слов, но я, если честно, думаю, что это даже преуменьшение: визуализация помогает обеспечить общее понимание идеи, упростить коммуникацию и устранить большую часть нюансов, присущих письменной и устной речи.

Мне хотелось бы показать вам шесть схем, которые я часто использую при обсуждении идей, касающихся управления продуктами. Они хорошо принимаются аудиторией и отлично передают суть. Вот эти схемы:

• «Менеджер по продукту как узкое место».
  
• «Воронка доставки продукта».
  
• «Классическое противостояние Waterfall — Agile».
  
• «Размер инициативы, риск и вовлечение руководства».
  
• «Бункеры знаний».
  
• «Важность сегментации».
  

Можете использовать их в своей работе каким угодно способом.

Переведено в Alconost

Мы поговорили о недостатках «красной» корпоративной культуры в первой части статьи. Но нужно понимать, что живучесть её объясняется тем, что такой тип культуры не только является самым большим, но и, одновременно, самым невидимым препятствием на пути развития российского бизнеса.

Система 5С Юрского периода

Хочу привести случай из своей практики. На одном из предприятий промышленной компании новое руководство с помпой объявило о внедрении Бережливого производства. Много говорилось о том, как этот новый подход выведет предприятие на новый уровень эффективности. И первым инструментом БП для внедрения была выбрана система 5С на пилотном участке производственного склада.

Начальник склада встретил нас с большим энтузиазмом и вместе с его командой мы приступили к первой стадии — сортировке, но под завалами старого хлама и ненужных деталей мы вдруг наткнулись на интересное археологическое открытие — старые выцветшие таблички с инструкциями и плакатами 5С и остатки специфической разметки краской на полу.

— Так это мы уже один раз внедряли 5С три года назад! – радостно пояснил начальник участка, увидев немой вопрос в моих глазах. – Просто со временем как-то всё забылось…

Я поинтересовался, а нужно ли внедрять этот инструмент, если он всё равно его не применяет.

«Ну как же не внедрять? Дело-то хорошее», — ответил он.

Интро

К сожалению, большая часть работы тимлида скрыта от команды. И в зависимости от многочисленных факторов, таких как размер команды, выстроенные процессы, наличие других ролей, занимающихся работой с командой — она еще и невероятно размыта. Список твоих обязанностей в разных компаниях будет отличаться. Где-то это просто формальная должность человека, который просто перетаскивает задачи из одного статуса в другой в свободное время от написания кода, в другой — это полноценная роль, где придется отложить в сторону свою любимую IDE и заняться кучей других обязанностей. Кстати, очень часто эту роль совмещают с еще одной ролью, техлида, и далеко не всегда это плохо.

Но один момент не меняется — если ты стал тимлидом, в твоей жизни изменится многое, если этого не произошло, это первый знак, говорящий о том, что ты явно не справляешься со своими обязанностями (либо это звание носит сугубо формальный характер).

Если ты никогда раньше этим не занимался, тебе предстоит свой долгий и тернистый путь с огромным количеством разбросанных граблей, на которые тебе придется наткнуться и без поддержки команды, увы, этот путь преодолеть будет невозможно.

Подсказка: явно не ваших пользователей.

Поднимите руку те, чья компания провозгласила «Клиентоориентированность» как одну из своих корпоративных ценностей. Для тех из вас, кто читает этот текст на Хабре и не видит аудиторию: почти весь зал поднял руку, кроме пары человек сзади.

Они работают в Oracle.

Удовлетворенность клиентов является одной из корпоративных ценностей компании Oracle. Но корпоративные ценности — они как абонемент в спортзал — недостаточно их просто иметь.

Одержимость клиентами — полезная вещь, но есть ещё одна вещь, которой одержимы многие компании — это сроки. Дедлайны — это хорошо. «Будет готово, когда я закончу» может быть отличной (или даже рекомендованной) стратегией для двух человек работающих над одним приложением. Но когда вы работаете в компании с более чем двумя сотнями сотрудников, вам требуется некоторое понимание того, что происходит; примерное представление о том, когда ваши пользователи смогут использовать ваши новые свистелки и перделки.

Смею утверждать, что жестко установленные сроки — это плохие сроки, и если у вашей компании такие есть, возможно следует пойти еще дальше, и убрать пункт об «клиентоориентированности» из списка корпоративных ценностей. Потому что, хотите верьте, хотите нет, пользователям плевать на заваленные спринты.

Дедлайны нужны в первую очередь не клиентам, а менеджменту.

Хочу поделиться с вами планами по развитию YouTrack в 2020 году. Основные изменения, над которыми мы сейчас работаем, — это раздел “Статьи” (так мы назвали редактируемые страницы базы знаний), реакции в комментариях к задачам, Helpdesk, поставляемый практически “из коробки”, упрощенный пользовательский интерфейс и папки “Входящие” для уведомлений.

«— Скажите, пожалуйста, куда мне отсюда идти? — А куда ты хочешь попасть? — ответил Кот. — Мне все равно… — сказала Алиса. — Тогда все равно, куда и идти, — заметил Кот.» (С) «Алиса в стране чудес»

Низкая производительность труда в России

Думаю, что те из вас, кто был в Греции, ни за что не согласятся, что греки работают лучше россиян. Тем не менее, по исследованиям Организации экономического сотрудничества и развития (ОСЭР) Россия со своим показателем производительности труда на уровне $26,5 в час уступает всем странам ОЭСР (по сути все развитые страны), включая Грецию, кроме Мексики, где он составляет $21,6. Средний для ОЭСР показатель — $54,8, а у лидеров — Ирландии и Люксембурга — на уровне $99 в час.

В один прекрасный летний день к нашей команде пришла коллега из отдела контента сайта и попросила сделать инструмент для публикации информации о работе кафе и туалетов во всех магазинах страны. И все бы ничего, только мы не имеем никакого отношения к кафе и туалетам, а занимаемся “Платформой услуг”, благодаря которой наши клиенты могут нанять профессионалов в ремонте и обустройстве дома.

На мой вопрос: “Почему ты пришла к нам?” — мне был дан простой ответ: “Кафе и туалеты — это тоже услуги для клиентов!” Здесь вспоминаются слова Рене Декарта: “Если бы среди философов навсегда установилось согласие относительно значения слов, то почти все их споры были бы прекращены” (“Правила для руководства ума”).

Мы работаем продуктовой командой, и у меня встал вопрос: как описать наш продукт так, чтобы каждый понимал, что мы делаем и в чем мы можем помочь? Чтобы дать на него ответ, я решил разобраться, что означает само слово “продукт”.

Результат моих изысканий под катом…

Меня зовут Лена, и я принесла вам YouTrack. Вы наверняка слышали про этот сервис трекинга задач от JetBrains, а если нет — время познакомиться!

Мы выпустили новую версию и вот что происходит: появились новые функции и улучшения практически для всех сценариев использования YouTrack.

Самое большое изменение — новый с точки зрения дизайна и более производительный список задач, с обновленной боковой панелью и панелью инструментов, темным графическим режимом и многим другим. Среди других заметных новинок следующее.

Когда мы планируем разработку, в нашем бэклоге лежат задачи. Рядом с каждой из них могут незаметно притаиться риски — один или несколько. Давайте поговорим о том, как эти риски увидеть и что с ними делать потом. Это обобщение моего опыта в роли тимлида — что я делал по поводу рисков в бэклоге, что получалось, что нет.

Что такое риски? Риск это возможная проблема в будущем. В зависимости от разных факторов, эта проблема или случится или пройдет мимо нас. На часть факторов мы можем воздействовать, другие находятся вне нашего контроля.

Вот уже 7 лет, как я раз и навсегда «переехала» из реальных офисов в виртуальные. Мне гораздо комфортнее работать дома на удалёнке. Под «виртуальным офисом» я подразумеваю системы управления проектами. За годы дистанционной работы с разными компаниями и студиями я перепробовала их более 10 штук.

Поделюсь своим опытом использования 10 систем управления с точки зрения удобства коммуникаций. Для меня как для контент-маркетолога это имеет ключевое значение. Мне важно, чтобы сообщения и файлы не терялись. Смотрим, какой корпоративный мессенджер справляется с этим лучше.



Сейчас я работаю с ребятами из YouGile, которые развивают свою собственную систему. Они делают акцент именно на активном общении, чтобы корпоративный мессенджер таким же удобным, как Телеграм.

Я оценивала удобство коммуникаций максимально объективно, по ряду критериев:

• «Есть ли чаты и живая лента?»
• «Насколько широк функционал комментариев?»
• «Есть ли интеграция с облачными хранилищами?»
• «Сколько ГБ в облаке на бесплатном тарифе?»
• «Можно ли хранить файлы в одном месте?»

Системы я расположила по моему рейтингу: от самых крутых до наиболее слабых. В конце обзора – сравнительная таблица.

Ранее в статье «JIRA как средство от бессонницы и нервных срывов» был предложен вариант применения JIRA для управления проектом по разработке программного обеспечения в интересах крупного государственного заказчика. Однако неосторожное обращение со средствами автоматизации управления на «цифровой кухне» может не только испортить продукт приготовления, но и привести к многочисленным травмам. В серии статей «Правила своевременного приготовления вкусного программного обеспечения» предполагается подробно исследовать правила организации работ на программном проекте с использованием катализатора под названием JIRA. Приветствуется любая критика.

Источник

Традиционно процесс разработки ПО сравнивается со строительством. Термин «архитектор» только укрепляет ассоциативную связь между этими процессами. Но современные реалии сделали эту модель неактуальной, потому что есть механизмы, которые она объяснить не может:

• Если мы делаем какой-то физический объект или продукт, то почему ПО никогда не считается законченным?
• Если мы говорим об инженерных решениях, то почему мы никогда не можем уверенно планировать наперед?
• Если мы — архитекторы или строители, то почему так много проектов заканчиваются полным провалом?
• И наконец, при наличии множества советов, best practices, принципов, книг и докладов о разработке ПО, почему так много проектов превращаются в невыносимое место для работы?

Предлагаю близкий к тексту перевод блестящего доклада Сары Мэй «Livable code», где она рассматривает все эти вопросы.

Что делать, если вы не знаете, что такое Скрам?

В первую очередь стоит хотя бы прочесть Руководство по Скраму (PDF) и начать ему следовать. Если вы не следуете этому руководству, значит вы делаете что угодно, только не Скрам. По сути Владелец продукта занимается максимизацией ценности продукта для конечного пользователя. Он может делегировать свои обязанности кому-то из команды, но отвечать за результат должен только он один. Также он должен быть единственным источником знаний о продукте для команды. Если у разработчика есть вопрос, он идет только к Владельцу продукта. Тот выясняет все детали, разруливает зависимости (если они есть) и согласует дальнейшие дествия с разработчиком.

Приглашаем 26 ноября на встречу сообщества практиков Agile в крупных организациях — Enterprise Agile Russia. Спикеры Технологического Центра Дойче Банка, Райффайзенбанка и компании Ингосстрах поделятся своим опытом Agile-процессов.

Подключайтесь к трансляции!

Картинка взята с данного ресурса.

Ваш конкурент или партнер уже внедрил Скрам и демонстрирует высокие результаты, и вы, конечно же, хотите добиться того же. У меня для вас плохие новости: при неправильном применении Скрам может быть вреден.

Вот, например, список ситуаций, выявленных эмпирическим путем, в которых Скрам может помешать вашей работе.

Хотя Daily Scrum или Stand-up встречи принципиально отличаются от отчетных встреч, иногда первые становятся похожими на вторые. Чтобы этого избежать, давайте рассмотрим отличия хорошего эффективного Daily/Stand-up и не лучшей сферической встречи по статусу в вакууме, а затем будем стараться придерживаться хороших практик или избегать плохих.

Гибкий суррогат

Словом «Scrum» называются, как минимум, две сущности: философия и фреймворк.
Философия, или подход к работе, описан в книге Джеффа Сазерленда.
Фреймворк, т.е. алгоритм действий, описан в документе под названием Scrum Guide.
Философия превратилась в фреймворк, потому что авторы философии хотели заработать на ней денег (по их собственным словам).

Фреймворк сильно упрощен, по сравнению с философией. Главное — упрощена, а точнее выкинута, цель.

Цель философии: ускорение достижения результата. Причем, в разы. В книге есть примеры ускорения в 8 раз.

Цель фреймворка: чтобы у вас был Scrum. Там так и написано: делаете по инструкции — у вас Scrum, нарушаете инструкцию — у вас не Scrum.

Фреймворк не предполагает ускорения достижения результата, вообще.

Люди, преподающие или внедряющие Scrum, работают с фреймворком. Рассказывают и внедряют алгоритм, не приводящий ни к каким результатам, кроме «у нас теперь Scrum».

Суть понятна. Философию продавать очень сложно. Фреймворк — проще.

Фреймворк — это продукт. Он, как положено, прошел «упаковку». Он прост, понятен, есть поддержка и много специалистов. Ничего не напоминает?

Всё хорошо, кроме результата — его нет.

Привет! Меня зовут Маша, я Scrum Master в ivi. Работаю с командами биллинга и веб-разработки и помогаю ребятам организовывать рабочие процессы так, чтобы не только эффективно достигать целей, которые ставит бизнес, но и получать удовольствие от того, что ты делаешь. В своих статьях хочу делиться опытом, как настраивать свою собственную работу и работу команд, если вы Scrum Master или Team Lead. А в этой статье давайте поговорим о важности культуры обратной связи.

Фидбэк от других участников команды является компасом, по которому каждый определяет, куда двигаться дальше. Согласно Патрику Ленсиони, один из пяти пороков команды — нетребовательность друг к другу. Этот порок достаточно сложно «вылечить». Но при этом он может оказаться губительным.

Присоединяйся к митапу от Scrum Community Райффайзенбанка сегодня, 29 октября, в Нагатино. В программе две важные темы — от теории до практики. Узнавайте новое вместе с участниками Скрам-сообщества Raiffeisen Digital.

Недавно, совершенно случайно, с подачи одного хорошего человека, родилась идея — к каждой статье прикладывать краткое содержание. Не аннотацию, не завлекаловку, а именно краткое содержание. Такое, чтобы можно было статью не читать вообще.

Я попробовал, и мне жутко понравилось. Но это пофиг — главное, что понравилось читателям. Начали возвращаться те, кто давно перестал читать, заклеймив меня графоманом. И другой хороший человек посоветовал написать краткое содержание для каждой старой статьи. Я согласился и теперь, между делом, пишу эти коротышки. Назвал их шортами.

Вашему вниманию предлагаю несколько таких шортов, по нескольким публикациям. Вдруг что-то полезное для себя найдете.