Как создать стартап

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

Как пошутил лектор, его девушка сказала, что с ним невозможно поссориться, т.к. он перестал говорить утверждениями, а стал говорить предположениями. Вот что кастдев с людьми делает. Слово "кажется" рулит!

PS: публичная преза ФРИИ по юнит-экономике (гуглите в интернете, этого не было на занятии)

Идея выбрана: ЗаявкаНаПокупку (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, метод пустого инбокса, метод критического пути, как правильно проводить совещания, ретроспективы, как писать минутки с митингов, фоллоуапы, использование планировщиков, как верифицировать эстимейты и скорость работы программистов (проговаривать задачи, промежуточные точки, создание общего видения). Как ничего не забывать и все успевать.