Управление разработкой *

Привет, Хабр! Меня зовут Александр Лукьянченко, я тимлид команды, которая занимается платформой в Авито. В этой статье я расскажу о проблемах, которые возникали у нас при построении платформы для инженеров и том, какие технические решения мы использовали, чтобы эти проблемы устранить. Текст охватывает ту часть наших наработок, которые потенциально можно переиспользовать другим компаниям.

На прошлой неделе мы выпустили расшифровку первой части онлайн-встречи «Управление разработкой в «горизонтальных» компаниях», где приняли участие СТО Райффайзенбанка, Mindbox и руководитель разработки в Циан. 

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

В основе многих наших действий или бездействий лежат неразрешенные конфликты.

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

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

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

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

Многие практики Теории Ограничений утверждают, что «Грозовая туча» работает.

Давайте проверим и попробуем применить разработанный Голдратом алгоритм к нескольким типичным конфликтам из области ИТ. Посмотрим, как это может нам помочь.

Финансовые компании находятся в поисках лучших решений, которые оптимизируют внутренние процессы разработки, разовьют IT-инфраструктуру в соответствии с требованиями бизнеса и позволят им выводить на рынок лучшие конкурентные продукты. Так, два года назад мы ступили на путь перевода разработки ЦФТ-банк на платформу CFT Platform IDE. Среди коллег по цеху ходят слухи, что это процесс невероятной сложности, ввиду чего не решаются приступить к делу. На своем примере мы докажем, что это вполне подъемный процесс и для вашей команды.

Зачем нужно SRE, когда есть DevOps, что такое SLO и бюджет на ошибки, каким компаниям точно не надо внедрять новую методологию, существуют ли джуниор-инженеры по SRE и сколько платят опытным. Об этом и не только говорили на митапе Слёрма «Профессия SRE: практика и мифы».

На YouTube можно посмотреть видеозапись встречи, а здесь мы приводим текстовую версию разговора с некоторыми сокращениями.

Бывает, что люди, близкие к теме разработки софта спрашивают: чем проектная работа отличается от создания MVP (Minimal Viable Product)? Понятно, что при этом у каждого спрашивающего свой контекст вопроса — соответственно, отвечать на него надо по-разному. Однако, если обобщить, то проект и разработка продукта сильно отличаются друг от друга. Вообще всем. Это не так-то легко объять, поэтому давайте попробуем разобраться в проблематике.

Проблематизация: проект или разработка продукта

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

фото с сайта pilot.com

В 2012 году Джессика МакКеллар с командой друзей из MIT (Массачусетский Технологический Институт) запустила стартап скрытого чата Zulip. Менее двух лет спустя его выкупил Dropbox. И в этом не было ничего необычного. С ее командой такое уже случалось, когда они так же быстро продали Ksplice компании Oracle. Такая бешеная гонка дала МакКеллар больше опыта в разнообразных возможностях менеджера, чем обычный инженер получает за всю карьеру. Она была тимлидом, основателем, техлидом в огромной корпорации, а сейчас руководит десятками сотрудников в быстрорастущем международном стартапе. (Да, она еще и значимая фигура в мире Python). В статье Джессика рассказывает о своем опыте и подходе к управлению командами.

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

Большинство систем мы пишем сами, но в то же время мы иногда используем и коммерческий софт. В целом можно сказать, что мы стараемся работать «модно-молодежно»: у нас есть автоматизация на Ansible (именно автоматизация, а не деплой), у нас есть CI/CD на Bamboo + Bitbucket. Есть оркестрация на Mesos, от него мы постепенно переходим к Kubernetes.

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

Наши проблемы

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

Из предыдущего вытекает еще одна проблема — это подход «У меня локально все работает, если у коллег в деве/проде не запустилось — это их проблемы, пускай сами разбираются». Подобная проблема есть, наверное, практически у всех. Как мы стараемся ее решать: по максимуму переносить окружения на единую платформу, в нашем случае Kubernetes с динамическими окружениями. 

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

На DevOops 2020 Moscow Барух Садогурский и Леонид Игольник рассказали, какими методами можно воспользоваться для влияния на стейкхолдеров, что кому говорить, как мотивировать и как работать с возражениями. Пожалуй, за исключением парапсихологических практик и гипноза (которые не стоит раскрывать неокрепшим умам), на этом докладе спикеры показали все способы влиять, не имея полномочий на благо наступления повсеместного DevOps в индустрии.

Под катом — расшифровка доклада, а также видео с конференции. Далее повествование ведется от лица спикеров.

Долгий запуск — опасность для любого проекта. Особенно в IT: eсли мы долгое время не получаем обратной связи от рынка и конечных пользователей — высокий риск сделать никому не нужный продукт.

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

Идея монетизации — оплата за размещенное объявление об объекте и помесячная подписка на расширенные инструменты для продажи недвижимости.

Для этого заказал разработку функционального онлайн-сервиса с внутренней CRM-системой, мессенджерами и сложной системой аналитики за 1.5 млн. рублей и 5 месяцев работы, снял офис, нанял менеджеров и запустил рекламу.

Примерно за полгода затраты превысили 2,5 млн. рублей и, судя по динамике, это было только начало.

30  октября мы провели встречу с СТО и техническими руководителями Райффайзенбанка, Mindbox и ЦИАН, где за два часа постарались максимально охватить непривычную для российского рынка IT-компаний тему управления разработкой без менеджеров. В ходе разговора выяснилось, что «плоскость» («горизонтальность») у каждой из приглашенных компаний — своя. Под катом — видео со встречи и расшифровка первой ее части.

Митап был длинный и насыщенный, поэтому мы разделили его на два поста: первый, вы читаете его сейчас, — это ответы гостей на вопросы, которые выбрали в нашем сообществе в Фейсбуке; вторая — ответы на вопросы «из зала» от слушателей — выйдет на следующей неделе.

• История изменений: с чего начали;
• Контроль версий: синхронизация и подключение среды разработки;
• Подключение Test и Prerelease к контролю версий;
• Как происходит сборка релиза сейчас и какие результаты получили на выходе.