Чтобы проверить Shape up в реальном кейсе разработки я решил продолжить решать кейс обработки результатов пульс‑опроса для наших HR'ов. В предыдущей серии я обрисовал требования к переносу функционала из гугл‑таблицы, обрабатываемой скриптом во внутри корпоративное приложение. По условиям у меня 80 рабочих(!) часов и ни в коем случае нельзя ухудшать UX.

Продолжаю серию статей про малоизвестную (надеюсь что пока!) методологию разработки, которая запала мне в душу. Запала настолько, что я хочу донести знания о ней до как можно большего количества людей.

Первая вводно-обзорная статья

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

Малый процент идей, в первом приближении оказавшихся целесообразными, ещё ждет этап реализации. А о том, как соотносятся изначальная задумка и конечный результат, красноречиво свидетельствует тот факт, что “Ожидание/Реальность” - это даже не просто мем, а целый отдельный жанр мемов.

Дисклеймер: пока сам Shape up в боевых условиях не довелось попробовать, но на бумаге оно решает многие проблемы, которые меня бесят в организации процессов разработки.

Некоторое время назад я мониторил забугорный рынок труда, на предмет удвоить а то и утроить свою ЗП на тот момент. В итоге я эту затею забросил через какое-то время, зато по ходу обогатился знаниями. В частности я наткнулся на компанию Process street, в блоге которой был описана методология Shape up. Там был описан очень заманчивый крючок для меня как для разработчика, так называемый 2х недельный cooldown после 6 недельного цикла. "В эти 2 недели наши разработчики занимаются на проекте всем чем захотят!" Прям так и было написано, возможно без восклицательного знака.