Agile *

Долгое нахождение в зоне комфорта ведёт к проблемам

Однажды, когда держала в руках карты для planning-poker с 5 ценностями SCRUM, я поняла, что отдельные ценности в нашей команде «проседают». Хотя в команде мы исповедуем именно их.

1. Иногда мы перестаем слышать заказчика, не достаточно погружаемся в задачу и не стараемся решить проблему заказчика на глубоком уровне. Это происходит по причине того, что мы достаточно долго работаем в зоне своей ответственности. И фокус нашего внимания постепенно сужается до круга наших непосредственных задач. На проблемы окружающих людей мы просто перестаём обращать внимание.
2. В силу проблемы, обозначенной пунктом выше, члены команды иногда могут позволить себе резко ответить коллегам, если те чего-то долго не могут понять. Такое отношение не стимулирует к открытости, в следующий раз человек лучше потратит несколько лишних часов, чем снова обратится за помощью.
3. Долгая работа в одной и той же зоне ответственности приводит к шаблонности мышления. Иногда мы решаем задачи по «накатанному» пути из-за боязни выйти из зоны комфорта, столкнуться с чем-то новым и даже банальной лени глубже исследовать вопрос.
4. Отдельные члены команды недостаточно открыты шарингу знаний из-за интровертности характера.

Всем привет! Тема Agile вечна, вот и в нашем офисе не так давно прошла ScrumTrek’овская кухня. На этот раз обсуждали работу с требованиями, искали новые подходы к разработке и решали, как найти ценность для продукта.

На встрече было 10 докладов от спикеров из М.Видео, ScrumTrek, ZeptoLab, Альфа-Банка, Сбербанка, Citigroup, EPAM, Renault Digital и Look At Media. Программа была насыщенная, так что не проходите мимо, наверняка найдёте что-то для себя интересное. Комментарии приветствуются!

Для особо нетерпеливых есть лайфхак: последней строкой я добавлю ссылку на все видео разом. Не благодарите.

Наверное, на Хабре не найдется человека, не слышавшего про Scrum – самую популярную в наше время методологию управления разработкой программного обеспечения. Обилие публикаций от «коучей», компаний, только начинающих работать по принципам Agile, или уже испробовавших их на практике, руководителей проектов и обычных разработчиков, довольных и недовольных, любящих и ненавидящих Scrum всем сердцем, всех их мы читали уже не раз.

Обычно, говоря про Scrum, люди говорят только про разработку софта, но сегодня Кодабра расскажет кое-что необычное, мы поведаем вам свой опыт использования гибкой методологии для «разработки» самого настоящего оффлайн-мероприятия с живыми людьми вместо кода, площадками вместо серверов и самой требовательной аудиторией – детьми. Это рассказ про необычный подход к организации крупнейшего в России фестиваля цифровых технологий для детей и подростков – Digital Fest 2017.

Продакт оунер. Владелец продукта. Продуктолог. PO.



Должность, которую часто считают синонимом «Менеджера проекта», благо ряд задач и обязанностей довольно схожи.

О том, кто такой продакт в понимании Альфа-Банка, что это за человек, что он умеет делать и как относится к своей команде, нам рассказал VDavydov Владимир Давыдов, руководитель по развитию цифровых каналов и продуктов Блока “Массовый бизнес”

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


В центре кадра — Julie Zhuo, product design director в Facebook

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

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

Учитывая что в Уфе зима приближается решительными марш-бросками, почему бы не поехать в конце октября на конференцию, куда-нибудь, где +20, и хоть немного, напоследок перед зимой, увидеть солнышко? Сказано-сделано: посмотрел конференции, сравнил докладчиков, посмотрел где еще есть early-bird access цены — и забронировал.

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

Конференция и организация

Agile Turkey Summit проходит уже не первый год, в отеле Wyndham Grand Levent в Стамбуле (в активно строящемся небоскребно-деловом районе Maslak). Продолжается мероприятие всего 1 день (выпавший в этом году на 19 октября), хотя мастер-классы и воркшопы прошли еще 18-го числа. 4-й конференц-этаж отеля явно неспособен принять ~800 посетителей, что особенно очевидно, когда всех пытаются накормить.

Есть исследования и великолепная инфографика о том, как Agile распространен в мире. Этим можно вдохновиться, но выводы очень далеки от нашей действительности. Там попросту очень мало респондентов с постсоветского пространства.

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

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

Можно ли сказать, что что-то из Agile используется в вашей компании?

Под катом первые графики, выводы, рассуждения и призыв пройти опрос.

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

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

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

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

Пару лет назад я уже рассказывал о нëм на HR Unconference. Но записи выступления нет, а знакомые, которые не могут найти себе людей в отдел, всë чаще интересуются деталями, так что я решил, наконец, подробно всë расписать, а заодно и опубликовать свой первый пост на Хабре, поделившись своими наработками с широким кругом читателей.

Пару лет назад я заходил к родственнику. Моему бедному кузену (а он генеральный директор страховой компании) продали «серебряную пулю Agile» — но она не сработала, и его это очень расстроило:

Чушь всё это! Мы начали делать всё совершенно иначе. Мы пригласили консультантов. Мы наняли специальных руководителей проектов. Не сработало! Ничего не изменилось. Никто ни за что не отвечает. Я слышу только оправдания.

Не помню, что я ответил тогда, но знаю, как ответил бы сегодня. Я бы набросал несколько рисунков, словом не упомянув Agile. Пришлось бы объяснить кузену несколько основных понятий…

Переведено в Alconost

1. КПД процесса

Мы провели опрос наших пользователей на тему “Нужна ли коробочная версия системы управления проектами?”. Для нас точный ответ на этот вопрос имеет большое значение. Определяет путь развития системы и приоритеты по новым функциям.



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

Под катом графики с результатами и наши выводы.

«У вас не будет второго шанса произвести первое впечатление» — этот афоризм прекрасно характеризует ситуацию, возникающую при введении новых услуг в эксплуатацию в сфере IT. В 2016 году Mars IS перешел на новую операционную модель, состоящую из 48 процессов, взаимосвязаных между собой, с тем чтобы обеспечивать эффективное функционирование IT-услуг. Наряду с такими широко используемыми процессами, как управление инцидентами, проблемами, изменениями и др., в новую операционную модель вошел процесс введения новых услуг в эксплуатацию (Service Introduction).

С одной стороны, программисты – мягко говоря не самые общительные люди на свете. Это нормально, ведь если разработчики вдруг станут разговорчивыми кто будет писать код? С другой – время одиночек прошло. Современное ПО разрабатывается командами и даже самые консервативные компании, вроде Сбербанка внедряют Agile. Agile manifest пропагандирует определенные ценности, в том числе: «Люди и взаимодействие важнее процессов и инструментов». Так что общение с коллегами – не прихоть, а потребность. Эта статья ориентирована на гибкие команды разработки: разработчиков, тим-лидов, аналитиков, тестировщиков и т.д.

Профессиональные PM вряд ли найдут здесь что-то новое. Если вы – «технарь» и хотите, чтобы вас как можно меньше отвлекали от основного вида деятельности и вам интересно при чем здесь Спарта, добро пожаловать под кат.

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или "Как рассказать дедушке" и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.


Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

_{*Из большого ежегодного опроса компаний от VersionOne}

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

Пару лет назад я встретился с родственником. Мой бедный двоюродный брат (генеральный директор страховой компании) продался Agile Silver Bullet и сильно пожалел. Он сказал что-то вроде:

Это надувательство! Мы изменили весь рабочий процесс. Мы пригласили консультантов. Мы наняли этих мастер-PMов. И ничего не работает! Нет никакого результата. Нет никакой ответственности. Все, что я получаю — это отмазки.

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

«Можно обманывать некоторых людей все время, всех людей некоторое время, но невозможно обманывать всех людей все время». Авраам Линкольн

Самое недооцененное, на чем может заработать каждая компании — это Сервис. Раза в два можно увеличить оборот, но придется быть честным до конца. Хитрить со всеми все время все равно не получится.

Свежая история, где клиент чувствует, что остался в дураках:
Заказал три ящика минералки.
Ошиблись и привезли три бутылки вместо трех ящиков.
Развели руками, увезли три бутылки, сказали, что на складе что-то пошло не так.
Никаких действий от магазина.
Позвонил, в поддержку. Удивились, посмеялись, сообщили, что составили запрос, специалист изучит и вынесет решение.
Через день пришло письмо с извинениями и скидкой 100 руб. на следующий заказ.
Написал в ответ “А может доставите мне мой заказ?”
Без реакций.

А экономика сервиса работает так:
Заказал три ящика минералки.
Ошиблись и привезли три бутылки.
Извинились. И через два часа привезли четыре ящика. Один подарили.
Делать заказы тут стал чаще.
Рассказал в течении месяца историю еще пяти знакомым, трое попробовали, один стал клиентом.
Потратили на меня меньше 600 руб., за год заработали от 30 000 руб.

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

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

Перевод статьи, написанной Scrum.org и DevOps Institute. Ссылка на оригинальный файл

От переводчика

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

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

Ссылки, которые были в основном документе, я поместил сразу в текст, они отделяются скобками и курсивом. Если были сомнения в корректности перевода термина, то я дублировал его в скобках на английском.

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

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

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

Предисловие

Не секрет, что правильно выстроенные бизнес-процессы нужны всем.
Отдельные граждане, отделы и целые компании с холдингами бегают кругами и воют о необходимости правильного обустройства всех и всяческих процессов. Всё должно быть посчитано, измерено, запланировано и выполнено в срок, в строгих рамках бюджета. Метрики и KPI, предсказуемость и прозрачность. Везде должен быть “внедрён” Agile. Все должны мыслить категориями Lean. Все должны думать о Business Value. И, будучи разбуженными ночью, — мгновенно ответить на вопрос: “каков LTV нашего пользователя?”

Отличный, рациональный подход.

В разработке программного обеспечения давно и прочно обосновался тренд “не изобретай велосипеда”.

Нужно разработать инсталлятор для нашего мега-продукта? Интегрироваться с внешней системой? Разработать кучу отчётов?

Не умничай, бери коробочное решение. Сэкономишь кучу времени, нервов, и, как результат, — денег компании.

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

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

Отличный, рациональный подход.

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

Итак, знакомьтесь с нашими героями

Лет 30 назад во многих книгах по искусственному интеллекту утверждалось, что в будущем общение человека с компьютером будет происходить на естественном языке, а все другие интерфейсы уйдут в прошлое. Такую же картину часто можно видеть в различных фантастических фильмах. Но действительно ли голосовой интерфейс эффективнее? В нашем опыте мы заменим систему управления проектами в организации на чатбот с голосовым интерфейсом и посмотрим, что произойдет.

Mars Information Services: добро пожаловать в Мars!

Мы начинаем серию публикаций о том, как устроена и работает IT-поддержка глобальной компании Mars, Incorporated, которая ведет свою деятельность почти в 80 странах и является одним из мировых лидеров по производству продуктов питания и кормов для домашних животных. Добро пожаловать в блог Mars Information Services (Mars IS).