Так что я не буду здесь говорить что-то из серии "все немецкие компании..." или "все российские разработчики" - понятно, что везде всё очень по-разному, и нельзя сказать, что в одной стране лучше чем в другой. Так что опишу здесь вкратце работу одной эффективной команды, опыт которой, на мой взгляд, может быть полезно перенять.
Итак, мои наблюдения за работой программистов в немецком банке, и их отличий от работы разработчиков в моем окружении.
1. Канбан-доска - основной инструмент сопровождения разработки
По отзывам программеров и менеджеров существенно повышает эффективность работы и упрощает понимание ситуации с проектом. По этой доске задачи переходят из одного состояния в другое, и все могут наглядно увидеть ход проекта. Канбан-доска может быть разной - у некоторых отделов - это огромная физическая доска на колесиках, по которой тикеты переходят по классическим трем колонкам "Offen - in Arbeit - Erledigt", ой, то-есть, простите "To do-Doing-Done". Кстати, рачительные немцы заодно эту доску используют в целях перегородки в комнате - не пропадать ли добру. И, опять же, вот такая, стоящая посреди прохода и видимая всем потенциально заинтересованным лицам доска - это тот самый, соответствующий ценностям Agile "информационный радиатор". Здесь позволю себе небольшое лирическое отступление (уже не про немецкую практику, а про гибкие подходы к управлению в целом) - "информационный радиатор" - это термин, введенный изначально в английском языке (где он смотрится чуть логичнее, чем в русском) в качестве противопоставления термину "информационный рефрижератор" (то бишь холодильник). Имеется в виду следующее: мы традиционно стараемся всю информацию по нашей работе по максимуму закрывать и изолировать. Как будто запирать внутри холодильника - чтобы кто не надо ничего лишнего не узнал. Дабы начальство лишних вопросов не задавало, коллеги советами не мучили, наши ошибки были со стороны не заметны и т. п. Так вот, современные Agile подходы к разработке, которые я всячески продвигаю и рекомендую, призывают практиковать противоположный подход к распространению информации: все, что не является явно конфиденциальным и коммерческой тайной - распространять как можно шире, и предлагать на рассмотрение всем заинтересованным лицам. Про преимущества такого подхода я немного расскажу ниже, когда буду говорить про командную работу.
Но канбан-доска, конечно же, необязательно будет физической, которую потрогать можно. Большая часть разработчиков в том самом немецком банке используют специальное ПО. А именно Jira от Atlassian - кстати, как и большинство других сторонников Agile - если посмотреть отчет Annual report от VersionOne, то Jira лидирует среди используемых программных продуктов.
В России, заметим, картинка другая - это видно, например, по отчету от ScrumTrek. Самодельное программное обеспечение лидирует.
Одно из удобств Jira - интеграция с другими продуктами от Atlassian, в частности в банке используют Confluence - как инструмент для управления проектами и wiki-систему с документацией по продуктам, и BitBucket - как систему, предоставляющую доступ к базе данных с разными версиями.
Предполагаю, что основная причина того, что российские пользователи существенно реже используют продукты Atlassian, чем западные коллеги - достаточно высокая стоимость использования. Я, например, наслышана про российские компании, например, использующие из экономии одного пользователя "на всех" - чтобы не платить за много лицензий сразу. Это сразу убирает половину плюсов от применения продукта - гораздо хуже видно, кто чем занимается. Но все равно оказывается достаточно удобным. Но это было лирическое отступление, давайте вернемся в немецкий банк.
2. Канбан-доска гибко адаптируется под нужный бизнес-процесс
Канбан-доска при доработке функционала приложений на самом деле, включает в себя вовсе не три вышеупомянутых статуса, а гораздо больше, и покрывает весь процесс работы с задачей.
Перый столбец: Бизнес-запрос. Хотелка от бизнеса, чего хочется получить на выходе. Оформленная в идеале в формате user story "как __________ мне нужно ___________ чтобы _____________ " .
Второй столбец: Технический концепт. Здесь хотелка от бизнеса уже превращается в конкретное техническое задание. На самом деле, ответственный этап - я была свидетелем тому, что ошибки, допущенные на этапе переформулирования бизнес-запроса в технический концепт приводили к тому, что много месяцев дальнейшей разработки проходили впустую - в результате получался ненужный заказчику продукт, который приходилось переделывать.
Зато, наоборот, если технический концепт сформулирован правильно - дальше в третьем столбце: Разработка, работа уже понятная и несложная, и с ней справится любой толковый Junior-программист. Кстати, в Германии сама по себе профессия программиста считается не очень сложной, и не требующей высшего образования. Соответствующую специальность можно получить по итогам 3-летнего обучения в колледже, для поступления в который необязательно получать полноценное среднее образование в гимназии, а достаточно более короткой и простой реальной школы. Ну, а по выпуску из колледжа разработчик уже будет продолжать свое образование в ходе профессиональной карьеры - разнообразные курсы повышения квалификации (от предлагаемого работодателем "обучения во время ланча", сопровождаемого бесплатными бутербродами, до выездных учебных курсов с экзаменами) предлагаются тем, кто хочет расти и развиваться в своей специальности. И, разумеется, серьезные профессионалы с соответствующим образованием тоже ценятся.
Важный момент - в противовес бытующему в некоторых компаниях стереотипу "программисты не тестируют" разработчик ответственен за то, чтобы передать на тестирование заведомо работающий продукт. Поэтому первый (или, если хотите, нулевой) этап тестирования, который осуществляется непосредственно разработчиком, прежде чем передать работу тестировщикам, включается в этап разработки.
Четвертый столбец: создание концепта тестирования. На этом месте структура канбан-доски перестает быть линейной, потому что концепт тестирования - то есть написание алгоритма для последующего тестирования, создается параллельно с самой разработкой. В некоторых проектах, преимущественно при создании продукта с нуля, применяется технология test driven development (TDD) - когда сначала пишутся тесты, а потом уже начинается непосредственно разработка. TDD в Германии вполне себе уважают, но в описываемой нами истории, когда речь идет о доработке и переработке уже созданного продукта, его применение оказывается нецелесообразным - поэтому тесты придумываются уже параллельно с разработкой. Задача создания концепта тестирования, что логично, считается более квалифицированной, чем собственно разработка.
Работы в следующих трех столбцах тоже могут идти параллельно, и, что характерно, ревью кода и тестированием практически всегда занимаются разные люди. И все эти разные люди - не тот, кто занимался непосредственно разработкой.
Пятый столбец: написание код ревью - то есть отсмотр кода более опытным коллегой с комментариями про надлежащие исправления. Опыт показывает, что практика код ревью повышает качество кода. Фокус внимания специалиста, осуществляющего эту работу, заключается во-первых, в выявлении явных алгоритмических дырок. А во-вторых, в проверке его логичности и понятности не только автору, но и экспертам сопровождения, которым этот продукт в дальнейшем поддерживать. Как я уже говорила раньше, те, кто пишут код ревью не проверяют работоспособность кода, их внимание - к "хорошему тону" программирования (см. статью про ректальное программирование на Инфостарте - вот в немецких банках его всячески выкорчевывают).
Шестой столбец: тестирование. Поскольку к программному обеспечению в банковской сфере требования серьезные, порядок тестирования как правило жестко регламентирован. Порядок тестирования более менее стандартный: обычное, интеграционное, регрессионное, пилотный проект. Как и на других этапах, здесь предполагается тесное сотрудничество разработчиков и тестировщиков. Благодаря плоской структуре команды и отсутствию “эффективных менеджеров”, рабочие совещания по ошибкам в ходе тестирования как правило бывают немноголюдными и конструктивными.
Седьмой столбец: документирование. Эти работы тоже идут параллельно с тестированием. Как и многие другие команды, практикующие принцип Agile “Работающий код важнее совершенной документации”, документирование здесь осуществляют после разработки, а не на этапе технического задания. Сюда входит как написание пользовательской документации для клиентов, так и подготовка инструкций для экспертов службы сопровождения.
Кстати сказать, технический долг на Канбан-доске не фиксируется (как, впрочем, и у большинства других команд, с которыми я сталкивалась), а устраняется в рабочем порядке по мере возможности и целесообразности.
3. Повышенное внимание командной работе
Довольно много внимания уделяется тому, чтобы люди, работающие вместе ощущали себя единой командой. Этому помогают, в частности, регулярные (чаще всего еженедельные) встречи отдела, посвященные обмену информации о работе. Каждый разработчик рассказывает о своих задачах на канбан-доске - как об уже выполненных, так и о тех, которые он планирует взять в работу. В результате получается, что каждый имеет хотя бы общее представление о работе своих коллег. Это создает чувство единой команды, мотивирует на более интенсивную работу (ну, по-крайней мере, в условиях немецкого банка мотивирует - я не берусь предсказывать, что будет при перенесении практики в вашу организацию, честное пионерское). Кстати, в Германии вообще принято работать в полную силу. В течение всего рабочего дня никому не придет в голову заняться личными делами или посидеть в соцсети - не то, чтобы это кто-то контролировал, но просто не принято. И еще один момент - сотрудники стараются уйти от многозадачности и минимизировать перескакивание с одной задачи на другую - потому что, как известно, на переключениях теряется очень много времени. Хотя не буду лукавить, совсем уйти от него не удается даже у педантичных немцев - очень часто один и тот же сотрудник работает на нескольких проектах одновременно, просто занимается вопросами последовательно (в один день одной, на следующий - другой), а не пытается в один день решить много задач.
Один из плюсов регулярного обмена информацией заключается еще и в том, что имея общее представление о работе друг друга, людям проще "подхватить" проект коллеги, если вдруг возникает такая необходимость. Например, в связи с внеплановым больничным или выходом в декрет (в декрет в Германии, кстати, папы часто уходят наравне с мамами - это вполне принятая практика). Ну и когда через некоторое время вам поручат новую для вас задачу - вспоминая прошлые совещания, вы сможете понять, кто из ваших коллег уже занимался аналогичными запросами и с кем можно посоветоваться.
Еще один момент - минимальное вмешательство руководства в повседневную работу разработчиков. У проектов (по-крайней мере, не очень масштабных) редко бывают менеджеры в традиционном смысле этого слова. То есть у каждого проекта есть ответственный, но чаще всего это один из разработчиков. Практика показывает, что когда проектом рулят менеджеры "далекие" от программирования, они гораздо чаще выдвигают невыполнимые требования и не понимают "духа" запроса клиента, фиксируясь на "букве" требований, чем РП, выросшие из разработчиков.
Анекдот в тему:
Сотрудники компании едут в автобусе на корпоратив за городом. Каждые 10 минут мужчина, сидящий в 3–м ряду, спрашивает у водителя, сколько километров проехали и когда он планирует быть на месте. Ответы водителя мужчина заносит в компьютер.
Молодой сотрудник, сидящий неподалёку, спрашивает у рядом сидящего коллеги: "Кто это и зачем он все время дергает водителя?"
"Это — новый эффективный менеджер, недавно наняли," — отвечает опытный коллега. "Ему поручили обеспечить доставку сотрудников на корпоратив, вот он и думает, что управляет процессом".
Кстати сказать, подход немцев к рефлексии немного отличается от американского. Американцы регулярно проводят выделенные ретроспективы, и вообще американские книги призывают до 40% (!!!!) времени заниматься рефлексией и размышлениями о том, как улучшить процессы. В Германии, разумеется, тоже усиленно думают, как работать эффективнее или хотя бы не повторять грабли прошлых проектов в следующий раз. Но (по-крайней мере, в тех командах, о которых я рассказываю) рефлексия здесь в большей степени вплетена в повседневную работу - какие-то решения и предложения обсуждаются на рабочих совещаниях, фиксируются в рабочей рассылке, в документации и т. п. - в том смысле, что для анализа не организуются отдельные мероприятия.
Еще одно условие плодотворной работы - как я уже говорила выше, достаточно плоская структура. Команда, в которую входят и разработчики, и тестировщики, и менеджеры, и эксперты техподдержки, и продажники (выступающие в роли владельцев продукта), воспринимает себя как единое целое. И сотрудники могут взаимодействовать напрямую, а не через менеджеров - что снижает потери информации и ускоряет решение вопросов.
В-общем, команда - решает всё. Так что желаем вам в новом году хорошей и плодотворно работающей команды!
Большое спасибо за помощь в подготовке этого материала сотрудникам немецкого банка, пожелавшим вместе с названием банка остаться неизвестными!..
Подробно про Канбан-систему, и как ее можно (а как не нужно) применять в проектах автоматизации буду рассказывать в рамках онлайн учебного курса по управлению проектами. Присоединяйтесь, пока есть места!..
Подробнее об управлении ИТ-проектами вы можете узнать на моих онлайн-курсах
