Идея выбрана: ЗаявкаНаПокупку (ZNP)

Насчет идей для разработки в процессе курса по продукт менеджменту. Шеф курса сказал, что обе идеи огонь (ЗаявкаНаПокупку (№49) и УберКодревью (№71), но лучше все-таки ЗаявкаНаПокупку (ZNP).

Я сделал презу для ZNP. Покритикуйте, плиз (донесение идеи, смысл, текст, картинки, шрифты и др)!

Ссылка на презу: https://docs.google.com/…/1LbMYxl2mI9LkGkmegmbNi20ou6…/edit…

Для каждого слайда внизу есть текст, как его буду озвучивать. Его тоже критикуйте

Ниже мнение шефа о предложенных идеях:

>>>

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

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

Что в сервисе “ЗаявкаНаПокупку” надо сильно поменять привычный уклад вещей и по сути продавцу нанять нового человека для участия в таких аукционах.

Что в сервисе “Убер для техлидов” надо учесть массу нюансов с учетом разного стиля кода и т.д.

Абсолютно личное мнение, сервис “ЗаявкаНаПокупку” кажется мне более перспективным, но я не эксперт рынка ни там ни там, поэтому надо брать и проверять гипотезы в реальности.

Насчет идеи УберКодревью (№71)

Насчет идеи УберКодревью (№71). Покастдевил в одной дружественной ИТ-компании (скрины далее). Я думал, что B2B проще. Если зашел в одну компанию, считай, жизнь удалась. А с B2C сплошной геморрой. Только привлек клиента (физика), как он уже отвалился и не факт, что стоимость его привлечения будет больше выручки с него. По хорошему, должно быть больше раза в 3. Но как выяснилось, с B2B все не так просто. Проблемы с приватностью данных клиента и подрядчика и интеллектуальной собственностью, даже при подписанных NDA. Кодревью сплачивает команду и улучшает код и вряд ли хорошие компании захотят иметь внешний кодревью. Это увеличивает стоимость контракта для клиента. Проблема этического толка – кто гарантирует, что внешний ревьюер не обругает код команды и не перетянет проект в свою компанию? И прочая и прочая. В общем, выглядит круто, интересно, технологично, но если копать дальше, наверняка вылезут и другие проблемы. Хотя, конечно, все надо исследовать и проверять.

Занятие 3. Управления командой

● 

Идеальная команда для создания продукта

● 

AGILE методология

● 

Игра «Kanban pizza»

Чему научитесь:

● 

Научитесь подбирать оптимальную методологию под команду и продукт. Внедрять методологию в разработку.

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

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

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

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

Было бы неплохо пригласить проджекта из топового диджитал агентства. Пусть он расскажет как выбивать ресурсы разработки и не порваться управляя 3-7 проектами одновременно и 20-40 чел в потенциальном подчинении (и никого в прямом из-за матричной иерархии). Про откаты по гос. тендерам тоже пусть расскажет, полезный навык для Москвы.

Что еще? Традиционно ругали водопадную модель разработки. Дохлого льва не пинает только ленивый. При том, что waterfall – прекрасная методология для проектов, где критически важно сделать "все или ничего". Вы же не захотите лететь в самолете, где не хватает маленькой такой кнопочки, из-за которой невозможно благополучное приземление? Я работал по водопаду в госконторе типа ОВИРа. И там да, никто в прод не запустит проект, который не будет поддерживать весь набор документов, который месяцами дотошно согласовывают юристы. Ну нельзя выдать паспорт человеку без фото, нельзя. А есть еще каскадный, итерационный RUP с CRами, где все становится совсем ОК, все же адекватные люди.

Была игра "канбан-пицца". Изготовление разных типов пицц из бумаги на время. Видимо, мы должны были организоваться, нарисовать канбан-доску и готовить по процессу. По факту был хаос, ор и я в спешке какой-то девушке ножницами чуть было не отрезал палец. Короче, мне не понравилось. Но тут, наверное, проблема во мне, а не в игре. Просто, не люблю суетиться. Еще в универе пока все резались в Starcraft и AgeOfEmpires мне больше были по нраву XCOM, HMM и прочие цифровые шахматы.

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

Но вуаля! Я наконец-то понял, что такое Канбан. Цель канбан – минимизировать WIP (work in progress), незавершенную работу. Чтобы в любой момент времени если процесс остановлен, было готово максимум завершенных задач.

А то кого не спрашивал, все хвалили канбан, мечтательно закатывали глаза, но что это, объяснить не могли. Обычно, говорили что-то вроде: "Канбан – это как Скрам, но без спринтов, ретро и продукт овнера. А вообще в канбане ничего этого нет, а нужно просто запланированную работу сделать в срок". Спасибо, блин, большое. Это как слепому объяснить: "Ну, слон это как зебра, но без полосок, с большими ушами и хоботом на морде".

ОК, я понял что такое канбан. И также понял, что он для ИТ совершенно бесполезен. Минимизировать WIP, вы серьезно? ОК, в одном проекте я управлял 3мя удаленными разрабами из Пензы. Если я видел, что у кого-то в прогрессе больше 1 задачи, то просил его немедленно это исправить, а если не помогало, то эскалировал вопрос его ПМу, чтобы тот починил процесс. Программист может кодить только одну задачу в один момент времени. Если в прогрессе >1 задачи, значит одну из них надо перевести в Hold. Если по ней что-то неясно, перевести в MoreInfoRequired на того, кто даст нужную инфу.

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

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

Перенесемся в начало 70х годов 20го века. СССР в застое и еле дышит от непомерных военных расходов. Китайцы забивают своих учителей мотыгами в рамках культурной революции. А как учителя закончились, переключаются на воробьев, т.к. великому Мао показалось, что они клюют слишком много зерна и на следующий год миллионы китайцев умирают от голода из-за расплодившихся насекомых.

А японская экономика с 50х годов на подъеме, демонстрируя уникальные 10% роста КАЖДЫЙ ГОД. Они уже 2ые в мире по ВВП и догонят США через десяток лет. На заводах Тойоты внедрена прогрессивная методика канбан, позволяющая выпускать точно в срок столько продукции, сколько запланировано. Япония крупнейший кредитор США, а их бытовая техника признак высокого статуса.

Но внезапно, все изменилось. Евреи раздали люлей своим соседям в Войне Судного дня. Те объявили нефтяное эмбарго. Нефть взлетела и спровоцировала кризис в развитых странах. В Японии случилась торговая война с США, которая закончилась ревальвацией иены и темпы роста упали с 8 до 2%. Южнокорейцы стали выпускать сравнимую по качеству продукцию, но в 2 раза дешевле. Китайцы взялись за ум, скупили или своровали патенты и стали производить товары ужасного качества, но в десять раз дешевле гигантскими объемами. И японское чудо кончилось.

НО БИЗНЕС-КОУЧЕЙ БЫЛО УЖЕ НЕ ОСТАНОВИТЬ. Инфоцыгане всех мастей продолжали по инерции расхвалить все японское по написанным 10 лет назад методичкам. Высокое качество – хотя это отстой, т.к. клиент выбирает по цене. Систему пожизненного найма – хотя это отстой, т.к. убивает креативность сотрудников, а если людей надо уволить, этого не делают и они висят на балансе компании. И, … тадам! КАНБАН.

При этом канбан был придуман для реального производства автомобилей, а не ИТ. Эта штука имеет смысл, если нужны готовые автомобили. Он радикально решил проблему перепроизводства, характерную для советской плановой экономики. Нельзя отделам завода ставить задачу "вкалывайте!" и в конце месяца иметь на складах 10 тысяч кузовов и 3 миллиона рулей. Как это относится к ИТ? Почему работать без спринтов плохо и надо просто фигачить без остановки? Канбан это просто "мы за все хорошее, против всего плохого" или это действительно СИСТЕМА разработки ПО? Много мы сейчас видим успешных транснациональных ИТ-корпораций из Японии, выпускающих массовый потребительский софт?

Свой единственный, к счастью, опыт работы по канбан вспоминаю с ужасом. Это была питерская ИТ-контора, связанная с немцами. Платили выше рынка, но там были ужасно тесные рабочие места, а мозг выносили в двойном объеме. Канбан, как его там понимали, означал, что в начале недели ПМ обещал клиенту поименный список фич, которые будут сделаны до следующего понедельника. При этом оценки команда не давала (в канбане нет такой бюрократии, как планнинг геймы!), задача оценивалась интуицией менеджера. И, собственно, все, крутись как можешь. Каждую пятницу до глубокой ночи и иногда по выходным народ допиливал код с ужасными костылями, лишь бы "сделать все по канбану". ПМ заказывал вечером в пятницу пиццу и считал, что все ОК – команда в едином порыве делает общее дело. Когда у меня стал дергаться глаз я оттуда свалил и жалел только о том, что не уволился в первые две недели, чтобы не испортить себе трудовую.

Фигня этот ваш канбан.