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

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

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

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

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

● 

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

● 

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

● 

Игра «Kanban pizza»

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

● 

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

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

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

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

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

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