Очень хорошая статья-размышление о важности планирования. Зачастую нам хочется рваться в бой — закрывать задачи, выполнять спринты, ставить галочки в таскменеджере. Но если присмотреться, то много задач делается потому что просто нужно что-то делать. Их актуальность теряется где-то в процессе, результат описывается как "сделать задачу", "внедрить технологию", "использовать X". Сам себя на этом иногда ловлю. Недостаточное внимание планированию можно сравнить с путешествием на автомобиле без навигатора, который тут час же перестроит маршрут, как только вы отклонитесь от пути. К сожалению, в работе над проектами мы часто выдвигаемся в путь, один раз мельком взглянув на карту со словами: "ну тут все понятно, поехали".
кстати перекликается с одной темой которуюя давно заметил... у каждого девелопера, даже мелкого задрота, есть некая персональная ответственность за угробленные проекты. ну как у хирурга свое кладбище :)
на каком-то этапе, часто именно девелопер или не успеваает доделать, или делает криво, или не то что надо - в общем из-за уходит окно возможностей. и фишка в том, что нельзя сказать что виновата команда или манагер - выглдит все именно так, несомненно, но - если разобраться внутри команды - то виноват часто один единсветнный человек.
это не плохо, это очень хорошо, когда это осознаешь - тогда даже мелкая програмерская позиция вовсе не кажется незначительной.
т.е. этап Implementation - тупо может быть загублен одним человеком, в результате чего весь процесс каг бы перескочит локальный возможный минимум и уйдет плясать, т.е. проект никогда не состоится.
Эти проблемы решаются нормальным управлением разработкой - один накосячил, а не проверили, что работает, или нет другого разработчика которому можно дать переделать, или нет опытного разработчика который бы сделал ревью кода и т.д.
точнее за деньги, которые приносит продуктКак раз именно это в заголовке и написано. Тратить время надо не на полировку сферического продукта в вакууме, а на заточку продукта под решение конкретных проблем.
Для b2b история интересная: данные через customer development, account management - > приоритезация гипотез - > постановка фичей на основе гипотез - > дизайн - > разработка - > ...
В b2c , на мой взгляд, "lean start-up" самый рабочий.
Очень хорошая статья-размышление о важности планирования. Зачастую нам хочется рваться в бой — закрывать задачи, выполнять спринты, ставить галочки в таскменеджере. Но если присмотреться, то много задач делается потому что просто нужно что-то делать. Их актуальность теряется где-то в процессе, результат описывается как "сделать задачу", "внедрить технологию", "использовать X". Сам себя на этом иногда ловлю.
Недостаточное внимание планированию можно сравнить с путешествием на автомобиле без навигатора, который тут час же перестроит маршрут, как только вы отклонитесь от пути. К сожалению, в работе над проектами мы часто выдвигаемся в путь, один раз мельком взглянув на карту со словами: "ну тут все понятно, поехали".
Только дополню: Семь раз отмерь, один отрежь.
кстати перекликается с одной темой которуюя давно заметил... у каждого девелопера, даже мелкого задрота, есть некая персональная ответственность за угробленные проекты. ну как у хирурга свое кладбище :)
на каком-то этапе, часто именно девелопер или не успеваает доделать, или делает криво, или не то что надо - в общем из-за уходит окно возможностей.
и фишка в том, что нельзя сказать что виновата команда или манагер - выглдит все именно так, несомненно, но - если разобраться внутри команды - то виноват часто один единсветнный человек.
это не плохо, это очень хорошо, когда это осознаешь - тогда даже мелкая програмерская позиция вовсе не кажется незначительной.
т.е. этап Implementation - тупо может быть загублен одним человеком, в результате чего весь процесс каг бы перескочит локальный возможный минимум и уйдет плясать, т.е. проект никогда не состоится.
Эти проблемы решаются нормальным управлением разработкой - один накосячил, а не проверили, что работает, или нет другого разработчика которому можно дать переделать, или нет опытного разработчика который бы сделал ревью кода и т.д.
Комментарий недоступен
Если продукт не решает проблем, то он нафиг не нужен и кто за него будет платить? Сосед из душа?
точнее за деньги, которые приносит продуктКак раз именно это в заголовке и написано. Тратить время надо не на полировку сферического продукта в вакууме, а на заточку продукта под решение конкретных проблем.
Один вопрос: зачем красить губы?
есть здравый смысл только вот сложно определить 10% ты или 20% времени затратил. нереально почти.
Для b2b история интересная: данные через customer development, account management - > приоритезация гипотез - > постановка фичей на основе гипотез - > дизайн - > разработка - > ...
В b2c , на мой взгляд, "lean start-up" самый рабочий.