конечной продукт-целевые клиенты,на которых клиент может максимально быстро заработать

Грубо говоря, получает ли он ощущение "работы с классными ребятами" ?

конечной продукт-целевые клиенты,на которых клиент может максимально быстро заработать

ну тогда у вас всё ок для вашей собственной ЦА :)

так я не про всё ок с нашей ЦА,я про защиту от дотошных чуваков,которые умничают где не надо

можно конкретней с какой частью манифеста?

А как этот метод связан с Agile?

Возможно я неправильно ставил вопрос вначале.Как юридически защититься от клиентов 1 тип- мудаков (не всегда это сразу понимаешь,если сразу понимаем,то мы отдаём деньги) 2 тип- начитались что то по маркетингу и начинают учить нас маркетингу и юзабилити (тут тоже речь о неконструктиве) *и при этом оставаться Агил

Всем привет! Ребята, поделитесь опытом :) У меня есть команда, которая разрабатывает подпродукты. В среднем на разработку одного уходит 2-4 месяца. Хочу наглядность сделать, смотрю в сторону скрама. Проблема в том, что для каждого из этих подпродуктов пишется в команде оч сложная серверная логика, и специфика диктует писать все сразу: никак не получается адекватно дробить эту разработку, чтобы можно итерационно тестировать результат после итераций. Так вот вопрос. Посоветуйте, как работать в итерациях и как показывать демо? (Можно смотреть интерфейсы для подпродукта, их тоже делают очень долго и много, но их можно на демо смотреть. Но мне кажется, это не правильно, раз нет серверной части. )

по факту функциональность мы определяем,так как мы маркетологи и делаем так,как нужно.И для аудитории клиента,а не для клиента.Потому,мы конечно,внимательно выслушиваем заказчика,но делаем как нужно,а не как клиент хочет.Но иногда у него есть хотелки,которые мы не прочь вставить в сайт(если это не будет мешать конверсиям),причём в 90% случаев его хотелки не улучшают конечный результат и он начинает(поиграйте со шрифтами,передвиньте картинку,и прочие мелочевки,которые в сумме несут урон нашему бизнесу,ну и его-так как из-за его хотелок он позже запустит реклму и позже получит своих клиентов)-так вот хочется как то защититься от этих бесполезных хотелок толи договором,толи ещё как

у меня арт-директор по этому поводу говорит, что таким клиентам нужен не дизайнер, а оператор графического софта...

Если уже ввязался

Мы в свое время поступили так. Делаем по ТЗ, все прочие доделки в разумных рамках (если маленькие и малобюджетные, то до 5ти максимум, это прям совсем максимум), все что большое и вообще меняет концепт - это новый функционал, и делается как за новый, т.е. доплата. Так начнут больше думать, а сколько было переделок. Когда вы скажите все, лимит исчерпан, платите, то вообще вдумчиво начнут подходить к переделкам, так как мало кто хочет платить за прихоти. Главное быть последовательным, если сказали что все переделки овер N доплата, то так и делайте, дадите слабину - сядут на шею. Когда мы внесли эти правила, то клиентам (было у нас парочку таких), сказали что у нас реструктуризация и у нас меняется условия работы со всеми клиентами. Они такие-то такие, согласны? Да, идете дальше. Нет, не идете дальше, сворачиваете работы и отдаете исходники. Пускай ищут других. (обычно не уходят, вернее типа ушли, а через неделю, две возвращаются, потому что за переделки другой студии им дают конские ценники). Будут уважительнее относиться, проверено лично.

А вы как декомпозируете эту сложную логику?

А вот к примеру в нашем случае клиент не должен писать тз,мы сами создаём тз.В принципе мы и продаём не сайты и рекламу,а результат-целевые клиенты.Т.е. нам в иделе от нашего клиента нужно: 1.Больше инфы о бизнесе и о продажах 2. Гипотезы по захвату клиентов 3.Обратная связь о результате:целевые/нецелевые приходят Всё Упаковываем мы и тз нам составлять.по факту мы уже больше года работаем вообще без тз С нашими целевыми всё круто,но пару раз ввязывались.1 раз с маркетологом который "что-то знает" и эти его знания очень мешали нам работать 2 раз клиент походу просёк что мы прислушиваемся и да,сел на шею.Но мы тз не составляем и в нём нет смысла в нашем случае

у нас тоже клиент не пишет ТЗ, ТЗ пишем мы и те же самые вопросы задаем для разработки) ТЗ согласуется с заказчиком, ТЗ написано в юзерсори, что понятно любому человеку, даже не разбирающимся в разработке. Если нет ТЗ, то что является результатом работы? За что клиент платит? Как проверить что вы выполнили свою услугу?

Хорошие вопросы,натолкнули на некоторые идеи,спасибо

Увы да. Можем видимость сделать. :) ну т.е. Для разраба будет не одна большая, а много относительно мелких задач, в последовательности, все красиво. Но по факту пока он 60-80% задачи не сделает - результат нельзя посмотреть. А то и все 80-100 порой( вот и получается, что с демо беда и спринты ломаются

Я не про демо. Есть же какая-то этапность решения? У вас же не реверс-инжиниринг протокола связи, где пока не вскроешь непонятно что делать и непонятно сколько осталось. Какие-то классы пишутся. Методы. Чтобы понимать где находишься. Есть ли такой план у разработчика?

Да, есть. Но результаты команды в итоге можно показать только на основе написанного решения. Я пробовал делать декомпозицию, задачи ставить в спринт - в итоге все равно ничего внятного до конца реализации показать не могут, а разработок ещё и страдает от «лишнего» контроля

дак это у нас не итерационно происходит ,а на постоянной основе,по другому в маркетинге никак. Речь не о конструктивных хотелках клиента,а на просто хотелках,либо придирках к дизайну,которые не являются гипотезами и на конверсии не повлияют,а просто в виде: " я хочу чтоб дождик капал" -Зачем? -Чтоб капал Как защититься от этой хрени,я про это

дак это у нас не итерационно происходит ,а на постоянной основе,по другому в маркетинге никак. Речь не о конструктивных хотелках клиента,а на просто хотелках,либо придирках к дизайну,которые не являются гипотезами и на конверсии не повлияют,а просто в виде: " я хочу чтоб дождик капал" -Зачем? -Чтоб капал Как защититься от этой хрени,я про это

Ну... например, не работайте с мудаками(с). Имхо, бороться с таким можно только репутацией. Как бы не относились к АртЛебедев, я видел, как они "увольняют" клиентов. Имхо, это неплохая практика, при условии, что вы понимаете вашу ЦА и как до нее достучаться, чтобы поток был достаточек для роста.

unusual так периодически делает. про еще 1 такую можно прочитать в книжке re:Work

Ну... например, не работайте с мудаками(с). Имхо, бороться с таким можно только репутацией. Как бы не относились к АртЛебедев, я видел, как они "увольняют" клиентов. Имхо, это неплохая практика, при условии, что вы понимаете вашу ЦА и как до нее достучаться, чтобы поток был достаточек для роста.

Мы тоже увольняем клиентов,но начальных стадиях работы,когда ввяжешься и сделаешь пол проекта,как то очень убыточно увольнять

Мы тоже увольняем клиентов,но начальных стадиях работы,когда ввяжешься и сделаешь пол проекта,как то очень убыточно увольнять

Коллеги, привет! Вопрос: какие критерии у РМов на джуна, мидла и синьора? Как определить пореалистичней? Что учитывается? Желательно Западное представление. Спасибо.

Если формально - разные уровни сертификации (camp/pmp, ipma a/b/c/d). Как в случае аджайла - не знаю. Если не формально - в зависимости от реалий организации. Бюджет проекта, размер команды, длительность.

если нет сертификации, то я джун?)

"Без бумажки ты букашка, а с бумажкой - человек!" :)

у меня начались суицидальные мысли🙊 простите за оффтоп

http://www.forbes.ru/karera-i-svoy-biznes/353053-lovushka-dlya-biznesa-shest-sluchaev-kogda-agile-bespolezen-i-opasen

Господи, зачем они пишут такие статьи?

не зачем, а почему) потому что типа «Форбс»

дважды интересно, когда смотришь на досье автора...

Андрей, мне тоже статья не очень, так сказать, но хотел бы услышать ваш разбор этой статьи. Вот прямо по пунктам. Почему, например, вы несогласны или согласны, что Agile не может быть в космической отрасли? и т.д. Я без всякой задней мысли, просто интересно именно ваше мнение послушать.

Ещё смешной момент - автор пишет, что Agile «неприменим в атомной отрасли», хотя на последней Agile Business Conference (организуемой тем же ScrumTrek’ом) выступал человек из Росатома и рассказывал, как с помощью Scrum-подобного процесса они перепроектировали реактор и корпус блока АЭС под требования конкретного заказчика :)

Денис, ок :) Только чуть позже.

Ещё смешной момент - автор пишет, что Agile «неприменим в атомной отрасли», хотя на последней Agile Business Conference (организуемой тем же ScrumTrek’ом) выступал человек из Росатома и рассказывал, как с помощью Scrum-подобного процесса они перепроектировали реактор и корпус блока АЭС под требования конкретного заказчика :)

Господи, зачем они пишут такие статьи?

Ещё смешной момент - автор пишет, что Agile «неприменим в атомной отрасли», хотя на последней Agile Business Conference (организуемой тем же ScrumTrek’ом) выступал человек из Росатома и рассказывал, как с помощью Scrum-подобного процесса они перепроектировали реактор и корпус блока АЭС под требования конкретного заказчика :)

Пчёлы против мёда - коучи СкрамТрека пишут статьи «почему не надо» )))

ну тут же обсуждалось на днях про увольнение клиентов. Может это тоже такой хитрый прием?

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