Agile-методология в россии

Kaiten

Сайтkaiten.ru.

Стоимость. Бесплатно с базовым функционалом. Продвинутые тарифы стоят от 420 до 560 рублей за пользователя в месяц.

Платформы. Веб-версия, приложения для смартфонов на iOS и Android.

Особенности. Поддерживает методологии Scrum и Kanban. В едином рабочем пространстве можно комбинировать сразу несколько досок, чтобы видеть картину целиком.

Есть графики контроля, которые помогают распределять нагрузку на сотрудников, анализировать слабые места в работе и избегать просрочек. Количество одновременно выполняемых задач ограничено, что позволяет работать эффективнее.

Аналитик в Agile

Сегодня в России и странах СНГ набирают популярность гибкие методологии разработки ПО. При рассмотрении возможности перехода на них (и даже в процессе перехода или начального использования), почти неизбежно встает целый ряд вопросов. Один из них состоит в необходимости участия бизнес аналитика в процессе разработки.
Привычный всем набор функций аналитика — сбор требований и написание подробной спецификации, как должна работать система. Еще перед запуском проекта требования должны быть собраны, спецификация написана, дизайны нарисованы, и только потом программисты начинают писать код. Эта красивая история написания программы редко соответствует действительности даже в проектах по методологии waterfall, не говоря уже о Scrum.
Проектная документация имеет тенденцию очень быстро устревать— в особенности в сочетании с Agile, где изменения — норма, а не форс-мажор.
В связи с этим в Agile-методологиях всячески советуется минимизировать документацию:

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

Но это вовсе не значит, что минимизировать надо все и до нуля. При полном отсутствии документации, скорее всего, возникнут следующие проблемы:

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

Аналитик внутри команды

Можно пойти еще дальше и поместить аналитика внутрь команды. Что это значит:

Аналитик сидит вместе со всеми, т. е. в одной комнате с разработчиками.
Аналитик участвует в Scrum-митингах с остальными (рассказывает, что делал вчера и что собирается делать сегодня).
Работа аналитика учитывается при планировании итерации.
Аналитик может привлекаться к нехарактерным для себя работам, чтобы помочь остальной команде в непростую минуту — например, подготовить тестовые данные, прогнать часть ручных тестов.

Звучит здорово. И работает здорово! Однако бывают обстоятельства, при которых схема не подходит:

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

Аналитик в Agile — золотая середина между крайностями:

Одна крайность	Золотая середина	Другая крайность
Команду не допускают к аналитической работе.	Agile	Разработчикам самим приходится полностью прояснять, что же нужно.
Аналитик мало общается с заказчиком.	Agile	Аналитик все время проводит у заказчика.
Подробные спецификации перед началом итерации.	Agile	Отсутствие какой-либо проработки требований до постановки их в итерацию.
Команда «с придыханием» относится к установкам аналитика.	Agile	Команда не доверяет результатам работы аналитика (не использует их).
Аналитик не участвует в тестировании (QA).	Agile	Аналитик вынужден постоянно «протыкать» много старых интерфейсов.
Команда воспринимает аналитика как руководителя.	Agile	Аналитик для команды — мальчик/девочка «на побегушках».
Аналитик взаимодействует с командой исключительно при помощи документации и баг-трекера.	Agile	Аналитик взаимодействует с командой исключительно посредством устных коммуникаций.
С заказчиком и пользователями общается только аналитик.	Agile	Все члены команды вынуждены плотно общаться с заказчиками и пользователями.

Как опросы помогают сделать дизайн продукта лучше

Опросы — это отличный способ хорошо узнать своих клиентов. Их можно составлять как вручную так и с помощью софта. Существует много разных типов опросов, но не запускайте их все одновременно — клиенты могут просто испугаться.

Создание дельного опроса это целое искусство, поэтому мы попросили команду Google Ventures поделиться опытом.

Советы по созданию эффективных опросов от Google Ventures:

На старте чётко определите свои цели относительно того, чему именно вы хотите узнать.
Делайте опросы как можно короче, таким образом вы раньше получите ответ.
Задавайте вопрос с целью улучшения опыта клиентов и развития продукта, а не просто с целью саморазвития.
Не стоит задавать вопросы, ответы на которые можно узнать самостоятельно. То есть не надо спрашивать у респондента о новых подписчиках нашего сервиса если эта информация уже есть в базе данных.
Выдавайте варианты ответа в случайном порядке, так вы избежите ошибки предпочтений к порядку расположения ответов.
В заключение обязательно задайте открытый вопрос: «Не хотели бы вы нам ещё что-нибудь сказать»? Дайте человеку возможность высказаться и возможно, вы услышите кое-что интересное. Кстати, это хороший способ подыскать кандидатов для интервью.
Прежде чем разослать результаты опроса проведите тестовую проверку на небольшой группе лиц. Это поможет обнаружить вопросы с потерявшимися ответами и определить места где человек может запутаться. Как можно внимательнее составляйте письмо для клиентов с просьбой принять участие в опросе. Помните что это сильно влияет на сроки ответа.

Agile — что это такое простыми словами

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

Новая система получила название «Agile software development», что переводится как «гибкая методология разработки». Ключевое слово здесь — гибкость. Вот какие идеи легли в основу Agile:

Коммуникация в команде важнее инструментария и методов.
Отлаженный продукт важнее бумаг и документов.
Позитивная связь с заказчиком важнее обсуждения пунктов договора.
Гибкость в решении задач важнее выполнения исходного плана.

Эти четыре идеи были собраны в Agile-манифест. Именно после его появления принципы Agile стали активно применяться. Небольшие фирмы и до этого использовали в работе похожие методы, но после выхода манифеста данный подход стал еще более популярным.

Основная задача команды разработчиков в рамках подхода Agile — быстрый выпуск качественного ПО. Вся работа должна занимать максимум два месяца. Программисты, заказчик и пользователи совместно решают вопросы по разработке. Здесь важна регулярная коммуникация, чтобы оперативно вносить изменения по ходу проекта. Возникающие вопросы решаются на личных встречах, не создавая лишний документооборот.

Чтобы следовать в работе философии Agile, зачастую используют сочетания методов, например Scrum или экстремальное программирование. Они помогают выстроить процессы исходя из принципов Agile. Конечно, эти методы подстраивают и адаптируют под каждую команду, но главные идеи из Agile-манифеста остаются неизменными.

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

Однако у данной методологии есть и слабые места: необязательность составления технического задания, за счет чего заказчик может кардинально менять требования, и применение быстрых и простых решений, результат которых не всегда является наиболее качественным. Однако методы Agile отлично работают в рамках небольших команд и на этапе стартапов.

Манифест Agile

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

Идеи Agile:

Люди и их взаимодействие важнее, чем процессы и инструменты
Рабочее ПО важнее, чем документация
Клиенты и сотрудничество с ними важнее, чем контракт и обсуждение условий
Готовность к внесению изменений важнее, чем первоначальный план

Принципы Agile:

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

Постигая Agile, в дополнение к обзору идей и правил обязательно ознакомьтесь с этим небольшим видео, где специалист по проектному управлению, консультант и бизнес-тренер Алексей Таченков рассказывает об основах системы.

Чтобы реально осуществить на практике вышеизложенные идеи и принципы, необходимо придерживаться нескольких правил. Только тогда Agile-менеджмент проекта может быть эффективен.

Yandex Tracker

Сайтcloud.yandex.ru/services/tracker.

Стоимость. Бесплатно для команды до 5 человек. От 185 до 258 рублей в месяц за человека в зависимости от количества подключенных пользователей.

Платформы. Веб-версия, приложения для смартфонов на iOS и Android.

Особенности. В сервисе можно организовывать самые разные процессы: от дизайна и разработки приложений до работы отдела кадров и закупки оборудования. Задачи разных отделов можно вести в отдельных очередях: сотрудники не будут путаться, а руководители смогут оценивать и контролировать сразу все процессы.

Есть раздел «Статистика», в котором можно посмотреть сводную информацию по задачам из каждой очереди. Там же видны отчеты по временным затратам — это удобно, если сотрудники получают зарплату по часам.

Маркетинг, продажи и Agile

А теперь, внимание. Моя любимая история

«Привет, мы теперь используем Scrum/Kanban/другое слово в ИТ, у нас наладились отношения между закачиком и технической командой, мы “быстрее бежим», и меньше делаем дорогих ошибок, но прибыль что-то у компании не растет».

А еще и затраты стали больше, правда ведь? Консультанты, агенты по трансформации, повышение зарплат и так далее. А чего вы ждали-то? Вы разве к ИТ-отделу ходите за финотчетами?

Да, вы стали быстрее, вы стали делать меньше ошибок. И это только лишь фундамент. В маркетинге и продажах классические подходы тоже стремительно уходят в небытие, там появляются совершенно новые техники и новые иностранные слова:

Growth hacking.
Lean startup.
Lean marketing / UX.

И с этими словами тоже нужно познакомиться, потому что там где заканчивается Agile, начинается Business Agility — а это уже история для отдельной статьи.

Для чего внедрять гибкие методологии

Есть два подхода к разработке крупных проектов. Классический, или каскадный — это механика, в которой заранее готовится громадное техническое задание, учитываются все мелочи, предсказываются риски и затраты. И только потом начинается разработка. В digital такой метод работает неэффективно — когда команда разрабатывает большой проект, невозможно спрогнозировать все риски и проблемы.

Управление проектами в стиле Agile и Scrum — иной подход. В основе — итерации, небольшие задачи с минимумом функций. Можно разработать основные функции, запустить ПО и постепенно дополнять его.

Плюсы методологии:

Нет нужды составлять длинное ТЗ — вместо этого формируется гибкий список задач на основе желаний клиента.
Бюджет гибкий — если деньги закончились, заказчик все равно получит работающий проект, пусть и с меньшим количеством функций.
Меньше бюрократии — нет нужды согласовывать сразу всю документацию по проекту, достаточно получить одобрение руководителя по одному вопросу. Разработка других задач в это время не прекращается.

Agile — это подход к разработке большого проекта. Философия, которая позволяет создавать продукт с постоянно меняющимися требованиями.

Откуда взялся и как трансформировался agile?

Agile скоро будет 20 лет. Откуда эта новая технологическая религия взялась?

Agile появился у IT-специалистов не просто так. IT-отрасль достаточно молодая: от первых «гаражных» компаний, где делалось ПО и собирались компьютеры, до момента, когда были придуманы серьёзные системы по разработке программного обеспечения — прошло не так много времени. Эта отрасль сильно бюрократизировалась. А в забюрократизированных процессах мы не можем быстро разрабатывать инновационные продукты.

Встал вопрос — как же нам эти продукты инновационные выпускать. Частью этой истории является великая встреча на лыжном курорте светил от IT-бизнеса, от управления проектами в IT-сфере, каждый из которых привёз такую домашнюю заготовку — описание процесса, как он разрабатывал бы и разрабатывает инновационные продукты. Они на этом лыжном курорте собрались, начали смотреть — а что же между их процессами и придуманными схемами работы общего. Они создали некий документ, который получил название — agile-манифест.

Этот манифест содержит в себе 4 основных ценности и 12 принципов. Ценности:

люди и взаимодействие над процессами и инструментами;
рабочий продукт важнее, чем исчерпывающая документация;
взаимодействие с заказчиком важнее, чем согласование условий контракта;
реакция на изменение важнее, чем следование плану.

В рамках вот этого набора ценностей и разрабатываются современные подходы к созданию инновационных продуктов в IT-сфере, а теперь и в других сферах.

Прошло 20 лет, а отрасль гибкая, всё быстро меняется. С тех пор эти принципы остались в основе, но что поменялось? Есть ли какие-то нововведения?

Вопрос лукавый, на самом деле. Эти принципы переписывались много раз для разных отраслей. Занимаются переписыванием уже все кто попало. Но мы стараемся всё-таки держаться ближе к оригиналу.

Что произошло за эти 20 лет? Во-первых, был накоплен реально большой опыт и инженерная база того, как сделать существование гибких процессов разработки возможным. То есть технологическая революция происходила в разных отраслях, а в IT крупнее всего. Появились различные модели масштабирования. Начиная от достаточно серьёзных Scaled AgileFramework — это серьёзная штука для крупных организаций с уже жёсткими бюрократизированными процессами, заканчивая какими-то легковесными — наподобие инженерной культуры компании Spotify, которую сейчас все активно пытаются копировать.

Главное: agile не отвечает на один простой вопрос — как нам вести бизнес, то есть как сделать так, чтобы наша компания успешно выживала. Тут появляется новый термин, который называется businessagility.

Метод Agile: определение и краткая история

Как бы непривычно это ни звучало, но серьезно разрабатывать программное обеспечение и управлять проектами начали уже в 70-х годах прошлого века. Именно в 1970 году американский ученый-компьютерщик Уинстон Ройс составил документ, называвшийся «Управление развитием крупных программных систем». В нем он приводил критику последовательной разработки, указывая на то, что разработка программного обеспечения не должна походить на работу сборочной линии (как, например, делается в автомобильном производстве), где новые детали по очереди добавляются в последовательные фазы.

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

На основе этого в 90-х удалось создать комплекс гибких методов разработки ПО, способных заменить сложные и трудоемкие методы. Происходило это так:

В 1991 году появился метод быстрой разработки приложений RAD
В 1994 году появился метод разработки динамических систем DSDM
В 1995 году появилась платформа (фреймворк) гибкой разработки Scrum
В 1996 году появилась гибкая методология разработки Crystal Clear, а также экстремальное программирование XP
В 1997 году появилась итеративная методология разработки ПО FDD

Все вместе эти методы объединились под общим названием гибких методов разработки ПО.

Четыре года спустя – в 2001 году в штате Юта (США) на курорте Snowbird собрались семнадцать разработчиков программного обеспечения. В результате обсуждения методов разработки был опубликован «Манифест о гибкой разработке программного обеспечения Agile» (в переводе с английского понятие «agile» означает «подвижный», «проворный» или «быстрый», но в большинстве случаев его переводят именно как «гибкий»). Он и задал темп всей дальнейшей работе над созданием ПО.

Бизнес-консультант в малом и среднем-бизнесе. Кто это и зачем он нужен? Промо

Я не буду здесь давать сухие определения, думаю, они никому не интересны. Бизнес-консультант – это тот самый человек, которого приглашают со стороны, чтобы он помог найти решение каких-то проблем. Также очевидно, что взгляд «со стороны» очень часто помогает выявить то, что вы никогда не обнаружите, будучи сотрудником компании.
Я хочу с вами поговорить исключительно о бизнес-консультантах, которые работают с малым и средним бизнесом, т.к. с предприятиями с численностью сотрудников ориентировочно от 5 до 70 человек. Эта работа во многом отличается от того, что делают специалисты, которых привлекают в подобных случаях крупные компании. И, как раз, с этими нюансами есть смысл разобраться.

Метод управления проектами Waterfall

Цель всех процессов управление проектами – успешная реализация задуманного. Для этого необходимо выбрать эффективные методы, которые будут соответствовать особенностям вашего бизнеса. Так как не существует одинаковых проектов, также нет и универсальных методов, подходящих для любой ситуации.

Далее приведены методы, использующиеся чаще всего.

Waterfall – это водопадная модель процессов управления проектами, которую можно считать классической. Другое ее название – каскадная. Суть этого метода заключается в поэтапных и последовательных действиях. Важная каждая стадия, нельзя пропускать ни один шаг. Как только будет завершен предыдущий шаг, можно приступать к последующему.

Такая система процессов управления проектами будет состоять из следующих этапов, которые подходят для любой области деятельности:

обсуждаем идею;
анализируем требования к проекту, формируем ТЗ для исполнителей, оговариваем сроки и сумму, которая выделена для реализации проекта;
проектируем;
исполняем;
тестируем, вносим корректировки, устраняем допущенные ошибки;
внедряем продукт, осуществляем техподдержку.

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

Участники процесса управления проектами легко контролируют работу команды исполнителей за счет простой системы отчетности.

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

Чтобы реализовать проект, приходится отказаться от тестирования, это приводит к тому, что будут допущены ошибки. Чтобы устранить их после запуска продукта, придется потратить огромные суммы, особенно если сравнивать их с затратами на стадии разработки продукта.

Шустрее исследуй и созидай

Исследование клиентов хорошо впишется в любой рабочий процесс, в систему работы на любой позиции, и такой подход не зависит от размера компании

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

Есть два типа исследований, которые помогут вам лучше узнать своих клиентов.

Количественные: измеряют всё, что поддаётся измерению. В этом поле работ вы собираете аналитические данные о моделях поведения клиентов и строите поведенческую экономику в клиентских когортах.

Качественные: собирают данные о качествах и ценных для клиента свойствах продукта, а также об опыте его применения на практике. Например, после интервью с клиентом мы можем понять какие чувства он испытывает во время работы с нашим продуктом. Даже такой небольшой момент, как интервью, помогает выйти на мотивы и причины поведения клиентов.

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

Например, в 2018 году в MailChimp группа, занимавшаяся исследованием пользователей, получила важную количественную информацию: многие клиенты связали свои учётные записи с аккаунтами на Fb.

Имея у себя результаты количественных исследований команда сразу же начала думать над улучшением связки MailChimp-Fb. Как вдруг, результаты качественных исследований показали совсем другую картину. Основная часть клиентов подключали свой аккаунт с Fb только потому, что это действие выглядело обязательным учитывая популярность Fb. Что с этим делать дальше клиенты не знали и получается, сами не понимали для чего им нужна данная интеграция. После того как качественные результаты исследований прояснили ситуацию команда разработки немедленно сменила курс.

Применяйте только комбинацию исследований: количественные и качественные.

Результаты внедрения Agile

Все поставленные задачи были решены. Сервис Ticketland вошел в двадцатку Forbes, компанию оценили в 84,2 млн долларов. Для бизнеса такого рода это отличный результат.

Agile — это большая трансформация, которая идет во всем мире уже д авно. Кто-то скажет, что Scrum и Agile — просто модные слова, оттюнингованный менеджмент и искусственный бум. Но есть классический кейс ФБР, где было потрачено 600 миллионов долларов, а результат появился только после перехода к гибкой методологии управления проектами.

Есть кейсы других крупных компаний. Посмотрите на них и задайте себе вопрос: «Зачем ездить по асфальту на коньках, если можно ехать на BMW?» Для современных проектов лучше работают современные работающие методологии.

Больше узнать про Agile и другие актуальные методологии управления процессами, применяемые в IT, маркетинге и медиа, вы сможете, пройдя наш курс «Управление digital-проектами».

Внедрили кросс-дисциплину t-shape

Этот элемент Agile, он означает осваивание новых знаний. Все в команде должны «говорить на одном языке», каждый должен стремиться расширить свой бэкграунд. Участники проекта должны быть специалистами в какой-то области, но при этом хорошо понимать кросс-дисциплинарные вещи.

Схематическое отображение t-shape

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

Важно!
Scrum-команды и люди в Scrum-командах должны быть специалистами в том, что они делают, и интересоваться смежными сферами.

Как внедрять agile?

Как люди пытаются начать использовать agile в работе и что для этого нужно?

Если мы хотим использовать agile в работе, то это значит, что мы будем менять процессы организации, а главное — мы будем менять организационную культуру, которую нельзя просто так внедрить. Её, скорее, можно вырастить, и это основной момент — agile не внедряется, а выращивается.

Всегда имеет значение контекст. В бизнесе нет общих паттернов. Взять даже какую-то одну страховую компанию, там есть успешные кейсы использования agile, в другой компании, возможно, что-то будет по-другому, опыт просто так, один в один, перенести нельзя. Поэтому чаще всего делается так называемый пилотный проект: набирается agile-команда, выбирается продукт, назначаются необходимые роли — и мы пытаемся этот продукт сделать. В ходе реализации мы натыкаемся на определённые препятствия.

Какие препятствия чаще всего бывают?

Первое — работа с подчинением, то есть людей не могут выделить конкретно в команду и дать им самоорганизоваться там. Не могут выделить на полное время. Потом начинаются проблемы более высокого порядка — с бюджетированием проекта: если обычно есть годовой план по бюджетам, то в agile бюджетирование строится немного по-другому, там скользящим «окошечком» делается это. Какие-то внутренние комплаенсы, безопасность, где может что-то пойти не так. В каждой организации могут возникать такие проблемы.

Этот пилот должен дать нам ответы на вопросы: как agile-культура в нашей организации помещается, что это такое — agile в нашей организации. А потом, набравшись опыта, мы можем этот опыт масштабировать на всю компанию или на ту её часть, которая нам требуется.

Есть какие-то противопоказания использования agile в командах? В каких процессах agile не работает?

Мы разобрали тему, когда технологически нельзя реализовать по agile какие-то вещи.

Самая большая проблема — когда мы пытаемся agile-практики применять в функциональных подразделениях. Например, заставить работать бухгалтерию или маркетологов по agile. Вот в этом как раз смысла нет.

Почему по agile мы можем делать продукты и реагировать на изменения рынка быстро? В команду мы набираем всех специалистов, которые потребуются нам для создания продукта. Команда должна быть кроссфункциональной. Если для создания продукта нам нужен IT-специалист, тестировщик, аналитик, маркетолог, дизайнер, то эти люди включаются в команду. И мы стараемся, чтобы эта команда не была очень большая. Она делает работу end-to-end, от начала и до конца.

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

Статья, продолжающая цикл публикаций по классификации внутренних проектов, а вернее сказать, их отправная точка.
Ибо ведение проектов происходит не в вакууме, а во вполне конкретной организации, со своим уставом и иерархией отношений.
А что будет с тем, кто сунется со своим укладом в чужой монастырь, нам напомнили как раз в предновогодний вечер: «Да на кол его посадят, всего и делов.»
Чтобы этого не произошло с вами — присмотритесь к предполагаемому месту работы, а я с вами поделюсь очень интересной классификацией организаций от признанных гуру в этой области.
Из-за этого статья пригодится как HR-менеджерам, так и из соискателям. Прошу под кат…

Советы по проведению интервью с клиентами

Интервью с клиентами не обязательно должны быть связаны с проектом. Можно выделить пару дней в месяц на то чтобы просто пообщаться с ними по-человечески. Таким образом команда всегда будет чему-то учиться.
Проводить интервью должно ограниченное количество людей иначе ваш пользователь сойдёт с ума.
Проводить интервью и делать заметки должны разные люди. Так процесс будет протекать естественно и непрерывно.
Следите за изменениями в эмоциях клиента

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

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

Однажды, в MailChimp, мы с командой заметили один любопытный тренд, когда изучали клиентов, которые утекают от нас к крупным конкурентам. В одном из опросов, который появляется при удалении учетной записи был вопрос о причине удаления. Клиенты отвечали, что уходят к такому-то конкуренту. Мы договорились о 60-минутных интервью и два дня вложили в изучение причин.

Опрос подкинул нам вектор для раскопок, а интервью помогли выявить интересный нюанс. Оказалось, что у клиентов не было никаких проблем с пользой приложения, они ушли просто потому, что не почувствовали его мощности. Мы все это время бились над тем, чтобы сделать продукт простым, а они, оказывается, восприняли это как недостаток проработки. Клиенты хотели более сложный по ощущениям инструмент, чтобы чувствовать себя опытными профессионалами. Этот случай открыл нам глаза и запустил развитие нового продукта для MailChimp.