К основному контенту

Управление Продуктом. Часть 1. Ранняя Стадия.

Автор: Александр Якима.

Давно хотел написать об этом. Но работа в стартапах не очень много оставляет времени. Но наконец-то получилось.

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



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

В Силиконовой Долине Менеджер Продукта - такая же обычная профессия, как у нас java-разработчик, например. Нам приходилось работать с многими. Мы наблюдали и активно участвовали в рождении и развитии новых продуктов.

Причем тут гибкая разработка? Да, закономерный вопрос. Ответ тоже. Agile по своей природе не есть средство написания кода, а целостный метод разработки и развития продукта. Мы движемся в напряженном ритме одно- или двух-недельных итераций не только чтобы вовремя видеть и справляться с техническими рисками, но и полуаем крайне необходимую возможность валидировать продукт с высокой частотой.

Скачать Статью



ПОПУЛЯРНОЕ

Шаблоны декомпозиции Пользовательских Историй (User Stories)

Автор: Richard Lawrence
Переведено с английского проектом Agile Translations


Хорошие Пользовательские Истории следуют INVEST модели, предложенной Биллом Вейком (Bill Wake). Они независимые (Independent), обсуждаемые (Negotiable), ценные (Valuable), поддающиеся оценке (Estimable), небольшие (Small) и тестируемые (Testable). Именно требование к размеру приводит нас к необходимости делить большие Пользовательские Истории, однако, даже после разбиения, они все еще должны следовать этой модели.
Многие начинающие agile-команды пытаются разделять Пользовательские Истории по архитектурным слоям: одна история для пользовательского интерфейса, другая — для базы данных, и так далее. Такой подход может удовлетворять критерию “небольшая”, однако, не сможет похвастаться тем же в случае с “независимая” и “ценная”. За девять лет работы с гибкими методологиями, я определил девять шаблонов разбиения Пользовательских Историй на хорошие, небольшие истории.

Скрамбан - собираем лучшее

Автор: Илья Павличенко.


Иногда я слышу фразу - «теперь у нас будет СкрамБан». И, к сожалению, наблюдаю, что чаще всего это означает, что у команды теперь не будет ни полноценного Скрама, ни внедренного должным образом Канбана. Хотя это понятие (СкрамБан) подразумевает и первое, и второе. Таким образом, команды лишают себя преимуществ обоих методов, переходя в серую зону неопределенности.

Привожу цитату Алана Шалловея, одного из родоначальников Канбана (полностью его блог-пост по этому вопросу можно прочесть здесь):
«Теперь стало модно у многих Скрам команд уходить от итераций и кросс-функциональных команд и говорить, что теперь у них внедрен Канбан. Я принимаю то, что в Канбане отсутствует и первое, и второе. Но Канбан не определяется отсутствием итераций или кросс-функциональных команд. Он определяется визуализацией, управлением потока, наличием явных полиси и т.д. Если у вас был Скрам и вы решили уйти от итераций - у вас не Канбан. Вы даже и близко не подошли к тому, чтобы приблизиться…

Календарь тренингов по Agile

Наши партнёры по тренингам: