Комментарии 19
Как вы обеспечиваете любовь сотрудников к каждому проекту? Каждый раз набираете новую команду?
Я не совсем понимаю, почему вам не подошел Scrum.
По Scrum-у stakeholder вообще ничего не обязан знать о ваших методологиях, есть product owner, который регулирует все отношения между командой, и заказчиком. Вы можете приглашать его на демки ваших инкрементов, где он может что-то комментировать, не более. Решения по продукту принимает product owner. Сроки, бюджеты, набор фич и т.п. — команда получает от product owner-а, а не от заказчика.
Опять же, спринт можно и остановить, если заказчику (product owner-у) приперло (что вы, собственно, и делаете сейчас) — перепланировали, сделали, показали. Не обязательно все скидывать в беклог. Но стопить спринт — плохая практика, смена фокуса команды всегда выходит дороже.
Ну а все остальное, мне кажется, можно было вычитать из умных книжек, и курсов — не стоило тратить 3 года на понимание таких базовых вещей самостоятельно (если я правильно вас понял).
Я не совсем понимаю, почему вам не подошел Scrum.
По Scrum-у stakeholder вообще ничего не обязан знать о ваших методологиях, есть product owner, который регулирует все отношения между командой, и заказчиком. Вы можете приглашать его на демки ваших инкрементов, где он может что-то комментировать, не более. Решения по продукту принимает product owner. Сроки, бюджеты, набор фич и т.п. — команда получает от product owner-а, а не от заказчика.
Опять же, спринт можно и остановить, если заказчику (product owner-у) приперло (что вы, собственно, и делаете сейчас) — перепланировали, сделали, показали. Не обязательно все скидывать в беклог. Но стопить спринт — плохая практика, смена фокуса команды всегда выходит дороже.
Ну а все остальное, мне кажется, можно было вычитать из умных книжек, и курсов — не стоило тратить 3 года на понимание таких базовых вещей самостоятельно (если я правильно вас понял).
Я не совсем понимаю, почему вам не подошел Scrum
В теории все отлично. Но на практике заказчики оказались не готовы, чтобы Product owner был на нашей стороне. А со своей стороны они не могут обеспечить все, что требуется. Сейчас мы делаем во многом то же самое, но не пугаем заказчиков разными словами и не вовлекаем в подробности процесса.
Ну а все остальное, мне кажется, можно было вычитать из умных книжек, и курсов
Ну да, видимо, где-то есть такой правильный список книг и курсов, где всем рассказывают, как правильно. В жизни на это натыкаешься тогда, когда пришло время, иногда случайно, по рекомендации проверенных людей. И этот процесс занимает время. А еще, наверное, Вы знаете, где учат за 2 месяца быть идеальным владельцем ИТ-бизнеса. Чтобы шишек своих не набивать, а сразу так раз — и все уметь :-)
Как вы обеспечиваете любовь сотрудников к каждому проекту? Каждый раз набираете новую команду?
Команда у нас все 3 года почти не меняется. Стараемся проекты искать поинтереснее. Но об этом надо писать отдельно.
Заказчик и должен быть владельцем продукта. Участвовать в процессе и так далее. Если это не так, то вы получаете как-бы скрам, который как-бы работает.
Ну так в том и дело, что в заказной разработке очень сложно этого добиться. И это основная проблема, которую надо решить — доступ к владельцу. Если же он есть, то кто-то может и SCRUM делать, если работает. Нам показалось в нем многое недостаточным, а многое лишним.
Насчет скрама-то я с вами полностью согласен :) Сложный фреймворк, который сейчас пихают везде, нужно это или не нужно. К тому же имеет принципиальные изъяны, например, недоделки в спринтах выявленные на демо физически не успевают попасть в следующий спринт, и отправляются в отстойник полусырого функционала, который все больше разрастается со временем.
Не знаю, где вы находите таких золотых заказчиков? У нас даже самые лояльные практически не дают участвовать в составлении приоритета фич. Если им уперлось, то практически невозможно хоть что-то доказать. Из личных примеров: три часа я и менеджер проекта убеждали заказчика отказаться от непродуманной фичи, которая стоила месяц+. После трех часов он нас спросил что-то, что как мы думали, он понял еще в самом начале :) В итоге, мы так и не смогли пробить его мнение, сделали фичу, через итерацию ее выпилили, так как она реально была ненужна и не работала в его модели. А он не расстроился и даже не понял ничего. Третий или четвертый год его проект двигается, а принцип остался такой же, много чего делается просто так, а потом вываливается в ведро. Как с такими работать? А уж что касается UI/UX, то тут вообще идет настоящая война. Заказчики часто рубят все подряд и хотят г*, но свое и точка =)
Вы, получается, изначально ищете заказчика, готового принять вашу систему работы? Это круто, что у вас так получается, но в условиях жесткой конкуренции, даже упертого заказчика на лонг терм найти реальная проблема.
Ваша методика хороша, мы бы тоже рады работать по такой схеме, думать о UX, о пользователях и делать действительно полезные клиенто-ориентированные проекты, но заказчики все рубят. Может расскажете, как вы их убеждаете?
Вы, получается, изначально ищете заказчика, готового принять вашу систему работы? Это круто, что у вас так получается, но в условиях жесткой конкуренции, даже упертого заказчика на лонг терм найти реальная проблема.
Ваша методика хороша, мы бы тоже рады работать по такой схеме, думать о UX, о пользователях и делать действительно полезные клиенто-ориентированные проекты, но заказчики все рубят. Может расскажете, как вы их убеждаете?
Начинали мы тоже с таких заказчиков, о которых Вы говорите. Да и сейчас такие у нас остались, не без этого. Но есть уже 2 проекта, которые сделаны вот так.
Да, заказчиков приходится искать. Причем все это лучше всего работает, когда заказчик находится в Омске, когда можно прийти к нему в офис, а он может прийти к нам. На удаленке все это тяжело, конечно. Но возможно.
Одним из критериев является то, что заказчик должен быть настоящим бизнесменом. Который понимает, что все меняется с бешеной скоростью, и если не реагировать — то смерть, готов принимать удачные идеи хоть от уборщицы — если они приносят пользу бизнесу, стремится использовать любые новые подходы, если они помогают быстро понять, что полезно для бизнеса, а что нет.
Такие люди хорошо реагируют на критику через вопросы. Как я писала: «Что будет, если эта фича не появится сейчас/вообще?» Ни в коем случае нельзя говорить в духе: «Да это вам не нужно, мы совершенно точно знаем». Нет, не знаем. И мы не знаем точно, и он не знает. Мы можем только придумать способ с заказчиком вместе, как быстро проверить гипотезу о необходимости фичи.
Еще бывали случаи, когда все начиналось с жопо-часов, а потом постепенно заказчик начинал прислушиваться к нам потому, что мы разобрались в его бизнесе и начали задавать вопросы :-)
Еще помогает общаться непосредственно с владельцем бизнеса. Никакие его наемные работники не способны принять решение о том, что надо взять и выбросить 2 фичи, на которые уже потратили полгода. Они будут бояться, врать туда наверх что-то, о чем Вы не узнаете. Мы очень стараемся на старте понять, с кем мы имеем дело, и работать только в случае, если доступен владелец для принятия важных и — особенно — неудобных решений.
На первом видео в конце статьи на 59-й минуте встает дядька. Он директор производственной фирмы в Омске. Он весь доклад сидел со скептическим выражением на лице и пару раз язвительно сказал, что мы собрались заказчика учить, и это никаким заказчикам не нужно. А потом он начал задавать вопросы, как бы ему как заказчику научиться так работать и не могли бы мы это сделать. И сейчас он пришел уже и на второе мероприятие, зовет к себе в гости зайти и всячески рвется, чтобы его покоучили.
Поэтому просто берите и пробуйте. Начните с простого — с вопросов. С выяснения целевой аудитории и бизнес-целей. С первого раза может и не получится, но надо продолжать :-)
Да, заказчиков приходится искать. Причем все это лучше всего работает, когда заказчик находится в Омске, когда можно прийти к нему в офис, а он может прийти к нам. На удаленке все это тяжело, конечно. Но возможно.
Одним из критериев является то, что заказчик должен быть настоящим бизнесменом. Который понимает, что все меняется с бешеной скоростью, и если не реагировать — то смерть, готов принимать удачные идеи хоть от уборщицы — если они приносят пользу бизнесу, стремится использовать любые новые подходы, если они помогают быстро понять, что полезно для бизнеса, а что нет.
Такие люди хорошо реагируют на критику через вопросы. Как я писала: «Что будет, если эта фича не появится сейчас/вообще?» Ни в коем случае нельзя говорить в духе: «Да это вам не нужно, мы совершенно точно знаем». Нет, не знаем. И мы не знаем точно, и он не знает. Мы можем только придумать способ с заказчиком вместе, как быстро проверить гипотезу о необходимости фичи.
Еще бывали случаи, когда все начиналось с жопо-часов, а потом постепенно заказчик начинал прислушиваться к нам потому, что мы разобрались в его бизнесе и начали задавать вопросы :-)
Еще помогает общаться непосредственно с владельцем бизнеса. Никакие его наемные работники не способны принять решение о том, что надо взять и выбросить 2 фичи, на которые уже потратили полгода. Они будут бояться, врать туда наверх что-то, о чем Вы не узнаете. Мы очень стараемся на старте понять, с кем мы имеем дело, и работать только в случае, если доступен владелец для принятия важных и — особенно — неудобных решений.
На первом видео в конце статьи на 59-й минуте встает дядька. Он директор производственной фирмы в Омске. Он весь доклад сидел со скептическим выражением на лице и пару раз язвительно сказал, что мы собрались заказчика учить, и это никаким заказчикам не нужно. А потом он начал задавать вопросы, как бы ему как заказчику научиться так работать и не могли бы мы это сделать. И сейчас он пришел уже и на второе мероприятие, зовет к себе в гости зайти и всячески рвется, чтобы его покоучили.
Поэтому просто берите и пробуйте. Начните с простого — с вопросов. С выяснения целевой аудитории и бизнес-целей. С первого раза может и не получится, но надо продолжать :-)
Тут чисто работа менеджера, программисты хотят, но на своем уровне не могут. Мы в свою очередь больше думаем о своих проектах, так как любой заказчик на стороне это не тоже самое, что свое. В идеальных планах разогнать свой проект, который сейчас на старте, чтобы вся команда была на нем максимально задействована и постепенно отказаться от сторонних заказов. Но это планы на ближайшие несколько лет.
Ну свой проект-то мы тоже хотим :-) Но до этого еще, возможно, далеко. А аутсорсинг — это возможность поработать в разных продуктах за деньги заказчика. И прокачать все те навыки, которые необходимы для успешного старта и развития своего…
И еще — у нас нет менеджеров в чистом виде. Я программист, и Иван программист. А еще мы аналитики. Ну руководим немножко иногда :-) А программисты у нас общаются с заказчиком почти столько же, сколько мы, и задают те самые вопросы «Зачем?» и «Почему?» И это тоже одно из наших решений — не брать в команду равнодушных.
И еще — у нас нет менеджеров в чистом виде. Я программист, и Иван программист. А еще мы аналитики. Ну руководим немножко иногда :-) А программисты у нас общаются с заказчиком почти столько же, сколько мы, и задают те самые вопросы «Зачем?» и «Почему?» И это тоже одно из наших решений — не брать в команду равнодушных.
Мне всегда казалось несколько странным, что разработчики строят некую виртуальную реальность в виде среднего потребителя продукта и его поведения, даже придумывают настроения и роли. Если продукт для людей, то почему бы не включить в процесс создания продукта их? показывать им прототипы, обсуждать… У Вас не было такого опыта?
У нас пока нет живого опыта. Есть сейчас проект, на котором мы следим за отзывами и Яндекс.метрикой. Уже после релиза кое-что поменяли благодаря отзывам людей. Кроме того, я внимательно слежу за проектами типа Бухгалтерия.Контур и 2GIS и вижу, что предпринимают они.
Виртуальных, конечно, придумывают тогда, когда нет доступа к реальным. Но с реальными юзерами есть свои проблемы. Почти никогда нельзя спрашивать людей чего они хотят. Все, что они скажут, почти всегда неправда :-) При этом они это делают не по злобе. А просто потому, что они в тот момент действительно так думают. Тот же Стив Джобс и вовсе подстраивал в итоге аудиторию под свои продукты, а не наоборот.
Поэтому многие веб-сервисы делают так: выкатывают новую фичу или новый дизайн на часть аудитории и просто следят за метриками. Если основные показатели бизнеса растут, значит фичу/дизайн надо выкатить всем. Много есть разных вариантов, как это делать. Главное — чтобы были внятные метрики, по которым можно оценивать.
Еще очень хороший способ дать людям почувствовать пульс аудитории — посадить разработчиков на саппорт реальных пользователей на некоторое время. Так делает СКБ «Контур», например. Так делает Джоэль Спольски. После этого они очень ответственно начинают относиться к тому, что делают. Как только у нас появится такая возможность, я обязательно так сделаю.
Виртуальных, конечно, придумывают тогда, когда нет доступа к реальным. Но с реальными юзерами есть свои проблемы. Почти никогда нельзя спрашивать людей чего они хотят. Все, что они скажут, почти всегда неправда :-) При этом они это делают не по злобе. А просто потому, что они в тот момент действительно так думают. Тот же Стив Джобс и вовсе подстраивал в итоге аудиторию под свои продукты, а не наоборот.
Поэтому многие веб-сервисы делают так: выкатывают новую фичу или новый дизайн на часть аудитории и просто следят за метриками. Если основные показатели бизнеса растут, значит фичу/дизайн надо выкатить всем. Много есть разных вариантов, как это делать. Главное — чтобы были внятные метрики, по которым можно оценивать.
Еще очень хороший способ дать людям почувствовать пульс аудитории — посадить разработчиков на саппорт реальных пользователей на некоторое время. Так делает СКБ «Контур», например. Так делает Джоэль Спольски. После этого они очень ответственно начинают относиться к тому, что делают. Как только у нас появится такая возможность, я обязательно так сделаю.
Джобс в каком то смысле гений и то что он делал не способен сделать никто пока что. Отчасти с Вашим утверждением соглашусь, однако, если продукт делается для людей, он решает какие то их проблемы так ведь? Если это не игровой проект. А как можно решать проблемы пользователей без их участия… Можно на эту тему подискутировать в личке впрочем, а то это может быть уже не релевантно теме топика…
Так все же как быть с “А сколько потребуется спринтов до завершения проекта?”?
Спасибо вам!
Это первая статья с трезвым взглядом на данную проблематику. А то в последнее время встречаю только фанатов SCRUM или чего то ещё конкретного.
Это первая статья с трезвым взглядом на данную проблематику. А то в последнее время встречаю только фанатов SCRUM или чего то ещё конкретного.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Принцип YAGNI в управлении проектами