Games of Projects and Products

@projectsproducts Нравится 0

Канал для менеджеров проектов и руководителей продуктов:
- теория,
- интересные кейсы,
- полезные статьи,
- ссылки,
- обзоры.
Елена Тупикова(Котина), больше 10лет в управлении проектами и продуктами.
@elenakotina
Гео и язык канала
Россия, Русский


Написать автору
Гео канала
Россия
Язык канала
Русский
Категория
Бизнес и стартапы
Добавлен в индекс
09.12.2017 15:18
реклама
Топовая аналитика кремлевских интриг
ОКОЛОКРЕМЛЯ
Нужна платежеспособная аудитория?
Канал с 98% мужской аудитории. Без ботов и накруток
Психология трейдера-победителя.
Рынок Америки. Топовый канал по трейдингу.
300
подписчиков
~0
охват 1 публикации
~11
дневной охват
N/A
постов в день
N/A
ERR %
0
индекс цитирования
Последние публикации
Удалённые
С упоминаниями
Репосты
Отличная новость воскресенья!:) Дарю подарок!

Кто хочет онлайн билет на ProductSense?

Это конференция для менеджеров, которая будет идти два дня в Москве, 15 и 16 апреля.

https://productsense.io

Одному своему подписчику подарю билет на трансляцию (цена 8000 рублей).

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

Завтра утром одному из написавших пришлю логин-пароль на доступ к трансляции.
Читать полностью
Команда Разработки меняет Бэклог Спринта в течение всего Спринта, поэтому Бэклог Спринта проясняется. Это происходит по мере того, как Команда Разработки работает над планом и узнает новые детали о работе, необходимой для достижения Цели Спринта.

- Инкремент — это сумма завершенных во время Спринта Элементов Бэклога Продукта и всех инкрементов предыдущих Спринтов.

Полный текст руководства: https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf

#project #product
@projectsproducts
Attached file
Читать полностью
Выдержки из руководства по Скраму

Scrum - процессный фреймворк, который широко используется в работе над продуктами, услугами и в управлении организациями.

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


Скрам-команда:

- Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта.

- Команды Разработки: Оптимальный размер достаточно мал (3-9 человек), чтобы команда оставалась гибкой, и достаточно велик, чтобы выполнять значимую работу за время Спринта.

- Скрам-мастер несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он коучит, направляет, объясняет принципы и подходы.



События Скрама:

Каждое событие в Скраме (кроме Спринта) — это формальная возможность для инспекции и адаптации.

- Спринт — временной отрезок длительностью месяц или меньше, в течение которого создается «Готовый», то есть пригодный к использованию и выпуску Инкремент продукта.

Спринт состоит из:

- Планирования Спринта,
- Ежедневного Скрама,
- разработки,
- Обзора Спринта,
- Ретроспективы Спринта.

Спринт может быть отменен досрочно из-за потери актуальности Цели. Право на отмену Спринта имеет только Владелец Продукта.

- Задачи, над которыми будет трудиться Команда Разработки во время Спринта, определяются на Планировании Спринта. План создается совместными усилиями всей Скрам-Команды.

Владелец Продукта выносит на обсуждение два важных вопроса:
бизнес-цели, которые должны быть достигнуты в Спринте, и Элементы Бэклога Продукта, необходимые для достижения Цели Спринта.

Команда Разработки определяет количество Элементов Бэклога Продукта, которые могут быть выполнены в Спринте. Ей же принадлежит исключительное право оценивать объём работ, который по силам завершить в текущем Спринте.

Команда Разработки самоорганизуется как во время Спринта, так и во время его Планирования при работе над Бэклогом Спринта.

Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта.

- Ежедневный Скрам – это встреча Команды Разработки, которая проводится каждый день во время Спринта. Встреча не должна занимать более 15 минут, за которые Команда разработки планирует свою работу на ближайшие 24 часа.

Команда сама определяет формат встречи, но акцент всегда остается на достижении Цели Спринта.

Какие-то команды проведут дискуссию, какие-то будут использовать вопросы:

- Что я сделал вчера, что помогло Команде Разработки приблизиться к Цели Спринта?
- Что я сделаю сегодня, чтобы помочь Команде Разработки достичь Цели Спринта?
- Вижу ли я какие-либо препятствия, которые могут помешать мне или Команде Разработки достичь Цели Спринта?

- Обзор Спринта.

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

Результатом Обзора Спринта является пересмотренный Бэклог Продукта. Он включает в себя элементы, которые могут войти в следующий Спринт. Также Бэклог Продукта может быть изменен, если появились новые бизнес-возможности.

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

Ретроспектива Спринта проводится после Обзора Спринта и перед Планированием следующего Спринта.

К концу Ретроспективы Скрам-команда должна запланировать конкретные улучшения, которые она реализует в следующем Спринте.


Артефакты Скрама

- Бэклог Продукта – это упорядоченный список известных требований к продукту.

Владелец Продукта отслеживает общий объём работы как минимум на каждом Обзоре Спринта, он сравнивает его с объёмом, который оставался на предыдущих Обзорах Спринтов.

Для прогнозирования прогресса работы команды могут быть использованы различные практики, например, диаграммы сгорания работ (burn-down), burn-up диаграммы или кумулятивные диаграммы потока.

- Бэклог Спринта — это набор Элементов Бэклога, взятых в Спринт, плюс план по достижению Цели Спринта и поставке Инкремента Продукта.
Читать полностью
Команда Разработки меняет Бэклог Спринта в течение всего Спринта, поэтому Бэклог Спринта проясняется. Это происходит по мере того, как Команда Разработки работает над планом и узнает новые детали о работе, необходимой для достижения Цели Спринта.

- Инкремент — это сумма завершенных во время Спринта Элементов Бэклога Продукта и всех инкрементов предыдущих Спринтов.

Полный текст руководства: https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf

#project #product
@projectsproducts
Attached file
Читать полностью
Совет дня
Эмпатия

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

Нам в этом может помочь эмпатия.

Эмпати́я — осознанное сопереживание текущему эмоциональному состоянию другого человека без потери ощущения внешнего происхождения этого переживания.

Ролик, где Марк Руффало в постановке Улицы Сезам (той самой!) объясняет, что такое Эмпатия:

https://www.youtube.com/watch?v=9_1Rt1R4xbM
Читать полностью
Если вы любите слушать полезные подкасты, то рекомендую https://soundcloud.com/productsense

Уже 31 выпуск с крутыми Продактами о культуре, процессах, менеджерах, командах.

#product
@projectsproducts
Начала смотреть курс “Биология поведения человека” Роберта Сапольски (запись видео его лекций).

Рекомендую. Научно-популярно. Полезно для понимания людей.

Robert Morris Sapolsky - американский нейроэндокринолог, профессор биологии, неврологии и нейрохирургии в Стэнфордском университете, исследователь и автор книг.

https://www.youtube.com/playlist?list=PL8YZyma552VcePhq86dEkohvoTpWPuauk

Два основных тезиса курса:

1. Процессы в вашем организме сильно влияют на то, что происходит в вашей голове.

2. То, что происходит в вашей голове иногда влияет на все процессы вашего тела.

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

https://academy.yandex.ru/events/management/shmya_msk-2019/

Занятия пройдут в московском офисе Яндекса (Льва Толстого, 16). Всем студентам из других городов и стран мы оплатим дорогу и проживание.

В этом году обязательным для поступления является просмотр курса https://www.youtube.com/playlist?list=PLEs8EuAPI73Bj78n7-BIW3s1we0r15yJl
Прекрасная статья про стадии жизни стартапа/продукта и инструкция "Что делать?" для каждого этапа.

http://laurenrbass.com/blog/5-phases-of-the-startup-lifecycle-morgan-brown

Стадии:
- Problem/Solution Fit
- Minimum Viable Product (MVP)
- Product/Market Fit
Language/Market Fit
Funnel Optimization
Channel/Product Fit
- Scale
- Maturity
Пост про любовь к работе.

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

Ниже цитаты из книги "Баристология" (Глеб Невейкин, Надя Мотылькова):

Вообще, в любой профессии видно тех, кто влюблен в дело, и тех, кто влюблен в себя в этом деле.
....
Кофе сегодня - молодой неизведанный продукт, у которого впереди целая жизнь, наполненная исследованиями, открытиями и переменами.
....
Форма, размер, материал, температура чашки способны превратить вкусный напиток в бесподобный.
....
Экспериментируйте, пробуйте разные варианты, вы удивитесь, каким разным может быть вкус одного и того же кофе при разных условиях заваривания.
....
Шоколад можно назвать старшим братом кофе, вместе им хорошо и по-семейному комфортно.
....
Почти с каждым из них он чувствует себя как в своей тарелке, с лёгкостью находя общие темы для разговора.
....
Интересно, что если перемешать все составляющие до того, как пить, то этот дерзкий обаятельный удалец тут же превращается в вялого тюфяка и совершенно ни на что не годится, разве только мусор выносить.
....
Общение с кофе не надоедает. Работаете вы с ним, изучаете, просто испытываете интерес или встречаетесь каждое утро в кофейне - не важно, какие у вас отношения, они никогда не станут обузой.
....
Про хорошего бариста: ... перед вами человек, ставящий кофе и ваши ожидания выше своих лени и комфорта.

Это я к чему? :)

Эта книга всего лишь про кофе.
Но с какой любовью она написана...

Важно выбирать работу не только по принципу "там больше платят", но и по "вашей любви" к ней.

#book
@projectsproducts
Читать полностью
Тест Джоэла.

Предназначен для оценки качества команды разработчиков.

Тест состоит из 12 вопросов:

1. Пользуетесь ли вы системой контроля версий?
2. Можете ли вы собрать проект за один шаг?
3. Выполняете ли вы ежедневные билды?
4. Используете ли вы базу данных ошибок?
5. Исправляете ли вы ошибки, перед тем как писать новый код?
6. Есть ли у вас актуальный план работ?
7. Имеется ли у вас спецификация?
8. Работают ли программисты в тихих условиях?
9. Используете ли вы лучшие средства, какие только можно купить?
10. Имеются ли у вас тестеры?
11. Пишут ли кандидаты на работу код во время собеседования?
12. Проводите ли вы коридорное тестирование удобства использования программы?

Счет, равный 12, — это прекрасно, 11 — удовлетворительно, а 10 или ниже означает, что вы столкнулись с серьезными проблемами. Правда заключается в том, что большинство программистских организаций наберет всего 2 или 3 балла, и им требуется серьезная помощь, ведь такие компании, как Microsoft, все время работают со счетом 12.

На мой взгляд, в устоявшихся компаниях менеджер оказывает наибольшее влияние на п.6, 7 и 12, поэтому привожу подробные цитаты Джоэла Спольски именно про них.

6. ЕСТЬ ЛИ У ВАС АКТУАЛЬНЫЙ ПЛАН РАБОТ?
Что заставляет нас составлять расписания? Если ваш код очень важен для бизнеса, то найдется много причин, почему бизнесу так важно знать, когда код будет сделан. Все знают, что программистов раздражает составление расписаний.

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

7. ИМЕЕТСЯ ЛИ У ВАС СПЕЦИФИКАЦИЯ?

Написание спецификаций похоже на чистку зубов вощеной ниткой: все согласны, что это полезно, но никто такого не делает.

Не знаю, почему это так, но, скорее всего, потому, что большинство программистов ненавидят писать документы. В результате, когда команды состоят исключительно из программистов, атакующих проблему, то эти программисты предпочитают выразить свое решение в коде, а не в документах. Они скорее углубятся в написание кода, чем вначале создадут спецификацию.

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

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

Эта проблема, возможно, была у Netscape, чьи первые четыре версии каждый раз по мере готовности превращались в такое месиво, что руководство приняло глупое решение выбросить весь имеющийся код и начинать все заново. А потом это руководство сделало такую же ошибку с проектом Mozilla, создав чудовище, вышедшее из-под контроля, и только спустя несколько лет этот проект добрался до стадии альфа-версии.

Моя излюбленная теория легко решит эту проблему, приучая программистов охотнее заниматься писательством (для этого их нужно отправить на интенсивные курсы). Другое решение состоит в том, чтобы нанимать способных менеджеров по разработке и сопровождению программ, которые будут писать
спецификации. В обоих случаях надо обеспечивать соблюдение простого правила: “Никакого кода без спецификации”.

12. ПРОВОДИТЕ ЛИ ВЫ КОРИДОРНОЕ ТЕСТИРОВАНИЕ УДОБСТВА ИСПОЛЬЗОВАНИЯ
ПРОГРАММЫ?
Читать полностью
Коридорное тестирование проводится так: вы перехватываете человека, идущего по коридору, и заставляете его использовать код, который вы только что написали. Проделав это с пятью людьми, вы узнаете 95% того, что вам нужно знать о проблемах с удобством использования в вашем коде.

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

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

#project #product
@projectsproducts
Читать полностью
Как бесполезные встречи крадут наше время

9 из 10 человек спят на встречах!
и это не шутка, знаю личные примеры :)

#project #product
@projectsproducts
Совет дня
Про разработчиков. (цитата Джоэла Спольски)

ОТНОСИТЕСЬ К НИМ, КАК К САМУРАЯМ

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

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

Этой деревней является ваша команда.

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

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

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

Уделяйте очень и очень большое внимание деталям всего процесса рекрутинга, проведения собеседований и найма, чтобы исключить из него какую-то случайную деталь, которая посылала бы вашим кандидатам-звездам единственное сообщение: “Вы не достойны!”

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

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

И наконец, если вы кому-то должны сказать “нет”, то делайте это быстро и с уважением.

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

#book #project
@projectsproducts
Читать полностью
Правила проведения встреч

https://www.ted.com/talks/david_grady_how_to_save_the_world_or_at_least_yourself_from_bad_meetings?referrer=playlist-work_smarter

“Каждый день мы позволяем свои коллегам, которые во всем остальном очень, очень милые люди, воровать у нас.
И я говорю о чем-то значительно более ценном, чем офисная мебель.
Я говорю о времени. Вашем времени.
На самом деле, я верю, что мы в центре глобальной эпидемии ужасной новой болезни, известной как СБС: Синдром Бездумного Согласия. (MAS. Mindless Accept Syndrome)”


То самое видео, которое Дэвид показывал в своем выступлении:
https://www.youtube.com/watch?v=zbJAJEtNUX0

#project #product
@projectsproducts
Читать полностью
Руководство к проведению собеседования
(продолжение из книги “Руководство Джоэла Спольски по подбору программистов и управлению ими“)

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

Часть вторая — это вопрос об одном из недавних проектов, над которыми работал кандидат.

Задавайте вопросы, допускающие разные толкования, после чего сидите и слушайте, только время от времени говоря: “Расскажите об этом поподробнее”, — на тот случай, если кажется, что кандидат вот"вот застопорится.

Что надо искать с помощью вопросов, допускающих различные толкования?

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

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

В-третьих, если проект, о котором рассказывают кандидаты, был коллективным, старайтесь узнать, брали ли они на себя руководство. Кандидат может сказать: “Мы работали над X, но начальник сказал Y, а клиент сказал Z”. Тут я спрашиваю: “И что же сделали вы?” Подходящий ответ на это может быть таким: “Я
встретился с другими людьми, занятыми в проекте, и написал предложение...”. А вот один из неподходящих ответов: “Ну, сделать я ничего не мог. Такая была ситуация”.

Помните: Будь способным и Доводи дело до конца.

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

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

Здесь я пропускаю большой кусок, так как предполагаю, что вы лично не оцениваете качество кода разработчиков. Но если это не так, то читайте в книге.


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

Кто-то из тех, кто проводит собеседования, стараются определить, задает ли кандидат “интеллектуальные” вопросы.

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

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

#book #project
@projectsproducts
Читать полностью