Оценка проектов
* Гигиенических навыков уже не хватает: нужно уметь мыслить и действовать, а не только следить за сроками. Невозможно просто ведя Jira привести проект к успеху. А если бы можно было бы, всех бы уволили и купили просто лицензионную Jira. Или украли бы.
* Продуктоводы должны давать оценку SMART, - ответы на эти простые вопросы ответственно организуют и позволяют трезво посмотреть на любые задачи.
* Тестировщики вступают в игру до разработчиков, - их тест-кейсы являются частью документации и кроме того описывают чёткие критерии для самопроверки разработчиками результатов их работы.
* Девопсы: секретное оружие - выходит строит проект без своих девопсов теперь можно смело называть попыткой суицида. По сути наличие девопсов сокращает сроки вывода релизов и починки аварий на порядок.
* Бюрократия важна - она позволяет проговорить формально все молчаливые соглашения и позволить не забыть их все. Таким образом устраняется на удивление огромная масса конфликтов при взаимодействии людей, отделов и компаний.
* Успех проекта, это когда техническая команда осилит разработку, а продуктовая сможет продать проект рынку. Увы одно без другого не работает. Мне довелось видеть, когда техническая команда сделала всё правильно, а продуктологи обосрались.
ВОПРОСЫ:
Харченко Андрей: Финальные сроки, когда оцениваются до MVP или уже после стартовых этапов? Т.е. заказчик говорит мне нужен проект за 2 квартала, после MVP, тестов, и фидбеков, и нового функционала после софт ланча, стало понятно понятно, что это нереально. Что в этом случае делать?Дело в том, что MVP представляет ценность не только с технической точки зрения, но ещё и с точки зрения бизнеса. Это УЖЕ работает и это УЖЕ принесло первый рубль. Но только после получения этого MVP вообще реально говорить о каких-либо сроках.
Как правило, бизнес в этот момент почти всегда перестраивается и в процессе торговли соглашается, что именно из общего объёма войдёт в те самые два квартала.
Это не работает в случае геймдева, но там и сроки другие и подход другой. Там на каждом этапе проверяется жизнеспособность гипотез, чтобы на любом этапе зафиксировать убытки и закрыть проект. Зато там цена выигрыша - экстенсивный (взрывной) рост и десятки миллионов прибыли. Не рублей.
Если же договорится с бизнесом (продуктоводами) не удаётся на этапе готового mvp (хотя повторюсь, mvp - это откопанное золото, радость от которого велика настолько, что танцуют все!), то проблема не в продукте, а в продуктоводах.
Бегите от них. Вообще берясь за любой проект 10 раз проверяйте, что продуктологи, маркетинг и коммерсы секуют фишку. Если нет, - они угробят всё и свалят вину на технарей. Это первое, чем они участя и в этом они эксперты!
Мурзин Андрей:
В текущих реалиях, к сожалению, этапность идея->mpv->оценка не часто реализуется. Главенствует концепция тендера. Кто сильнее прогнулся - того и контракт (во всех сферах, не только производства ПО). А далее только себестоимость уменьшать любой ценой со всеми вытекающими вплоть до провала.С тендерами не всё так очевидно. Различными махинациями эта тема модифициурется в 1) тестируем команду на лёгком проекте 2) разрабатываем план на несколько кусков работ, которые в целом образуют один большой проект, выкатываясь в продакшн по частям: сначала мвп, а потом доп проработки к каждой части 3) проводим серию тендеров с заранее определённым победителем.
На рынке существуют компании, который за 1% от суммы помогают выстраивать такие штуки. Общался с одной из них, - очень интересный опыт. Они вполне современные и по сути там работают одни из нас.
Мурзин Андрей: Про два часа на исследования, надеюсь, просто пример? Ограничивать время нужно, конечно. Лимит от задачи зависит.Да, разумеется лимит времени зависит от задачи, но всегда он должен быть с отсечкой: "сделай то, что успеешь за это время".
https://www.youtube.com/watch?v=Q3unJfSjAPE
