ещё
свернуть
Все статьи номера
2
Февраль 2017года
Excellence in tools
Менеджмент

Взлом корпоративного жаргона: что на самом деле означает понятие «Разработческая культура»

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

Ник Чиуботариу, старший менеджер по развитию программного обеспечения Amazon

Хорошо, когда в компании понимают важность корпоративной культуры. Но являются ли её основополагающими элементами «непрерывное развёртывание», «архитектура микросервисов», TDD и прочие подобные термины? Или суть заключается в чём-то другом?

Например, разобраться в схемах разработческой культуры компании Spotify (музыкальный стриминговый сервис) не просто сложно, а практически невозможно (рис. 1).

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

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

  • В вашей компании есть разработчики?
  • Они что-то создают?

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

Главное — «культура»

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

Рисунок 1.Диаграмма разработческой культуры компании Spotify

Это и есть основа любой разработческой культуры. Создаёте ли вы роботов, системы бухучета, приложения для iOS или облачные услуги, если ваши разработчики (а на самом деле — вся ваша компания) полностью не привержены этому и/или не наделены полномочиями, дальше можете даже не читать. Пока это утверждение не станет приоритетом № 1, всё остальное, в общем-то, неважно.

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

TDD

Глоссарий

(Test Driven Design)

Разработка (программного обеспечения) на основе тестов.

Принцип 1

Поддерживать личностное многообразие

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

Чтобы создавать великолепные продукты, нужно нанимать великолепных специалистов. Создание разработческой культуры требует хорошего понимания менталитета разработчиков. Большинство из них — независимые люди, не скрывающие своего мнения и, как правило, не соответствующие шаблонам. Многие отрицают дресс-код. Одни — «жаворонки», другие — «совы». Кто-то любит трудиться всю ночь, кому-то лучше всего работается до полудня. Есть интроверты, есть экстраверты. И задача компании — обеспечить совместную деятельность людей с разными типами личности, чтобы достичь гармонии и симбиоза.

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

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

Принцип 2

Вознаграждать за успех

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

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

Принцип 3

Не равнять всех под одну гребёнку

В компаниях Palantir и Spotify примерно по 1500 сотрудников. Google в ответ на запрос любезно сообщает точную цифру: 59 976. В Microsoft трудятся более 118 тыс. чел. Принципы, подходящие одной компании, могут не сработать в другой. Сдача продукта с определённым уровнем багов, т. е. ошибок в программе или системе, может быть приемлемой для социальной сети, но ни в коем случае не для производителя ПО, которое применяется в отделениях неотложной медицинской помощи или системе безопасности самолёта. Используйте хорошее и отбрасывайте то, что не подходит вашей компании. И это подводит нас к следующему принципу.

Принцип 4

Использовать правильные инструменты

Обратите внимание — не «лучшие»! «Лучшее» может быть разным для разных компаний. Какими бы инструментами, языками программирования, процессами и технологиями вы ни пользовались, они должны подходить именно вашей организации для разработки лучших продуктов, ориентированных на ваших конкретных заказчиков и целевые рынки. А для этого следует…

Принцип 5

Наделять разработчиков полномочиями

Это означает, что решения обо всём, что перечислено выше — какими инструментами пользоваться, какие процессы лучше всего подойдут, как должны функционировать организационные структуры, на какие технологии опереться, — принимают люди, которые непосредственно этим занимаются, а не топ-менеджеры, вне зависимости от организационной структуры компании. Воплотить этот принцип мало где удаётся. Примеры — Facebook, Google, Amazon, LinkedIn и некоторые стартапы. Однако в большинстве организаций руководители никак не могут удержаться, чтобы не отобрать инструменты у высококлассных специалистов, которых сами взяли на работу, чтобы они этими инструментами пользовались.

Почему так происходит? Большинство топ-менеджеров привыкли всё контролировать и никак не могут смириться с тем фактом, что в технологической отрасли оптимальное разделение задач — это позволить своим «войскам» внедрять технические инструменты и управлять ими («как построить ракету»), а высшему руководству — сосредоточиться на стратегическом направлении развития организации («куда запустить ракету»).

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

Принцип 6

Поднимать планку

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

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

Принцип 7

Проявлять гибкость, учиться и адаптироваться

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

Принцип 8

Получать от работы удовольствие и делать её с радостью

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

А ещё это место с высоким уровнем корпоративного духа, где персонал не перегружают (это особенно важно) и где можно повеселиться — например, пообедав вместе или отправившись после работы в бар, сыграв в футбол, выехав на шашлыки или занявшись спортом. Каждый сотрудник может сказать: «Мне здесь нравится, я рекомендую эту компанию своим друзьям». Возможно, это и станет окончательным критерием того, что в вашей компании, независимо от лозунгов, действительно есть прочная и эффективная разработческая культура, которой можно гордиться.