Alexey Rybak

2020-06-04 15:00:51 CTO vs CIO

Долго не писал – куча работы. Решил поменторить стартапы и поговорил, наверное, с 30 командами (трафик обеспечил Саша Горный в канале “Стартап Дня” @startupoftheday). Боли у команд и основателей настолько разные, что поста не хватит их описать. Почти все боли – известные боли роста. Особенный подвид в сегменте B2B-шников – сложные/дорогие продажи с доработкой/интеграцией дефокусируют конечное число инженеров, которые не успевают (и не понимают, куда всё идет). Попробуем с такими командами поработать, хотя, конечно, B2B – сектор не самый простой.

Ладно, теперь назад к тематике канала. Мы тут препарировали роль CTO, да не допрепарировали. Хочется вообще написать о зонах ответственности CTO, и об отличии CIO от CTO. Заранее извиняюсь за лонг-рид, не получается разбить пост на части. Если кратко и нет времени: CIO - это ИТ-директор, или “админ”. CTO - это техдир, или "разработчик". Дальше подробнее. У меня есть впечатление, что здесь имеется систематическое недопонимание. И если открыть википедию, там тоже какая-то муть написана. Итак, давайте посмотрим на это дело под углом “первопринципов”.

В любой компании есть IT-активы, которыми нужно управлять. Эти активы обычно являются комбинацией 3 вещей:
- Продукт для клиента. Это основной продукт/софт для клиентов, на которых зарабатываются деньги: сайт, сервис, платформа, мобильное приложение, проекты “под ключ” и т.д.
- Платформа для клиента. Вспомогательный софт и оборудование для клиентских платформ, эксплуатация которых находится внутри организации. На этом хозяйстве работает основной софт для клиентов. Если проекты отчуждаемы - этого хозяйства может не быть вовсе.
- Софт и оборудование для организации. На этом хозяйстве сотрудники делают работу: компьютеры и ноутбуки, офисная площадка, инфраструктурный софт, почта и базовый офисный софт, софт для бухгалтерии, маркетинга, аналитиков, IDE для программистов и так далее.

В executive team должен быть чувак, который в ответе за всю технологическую хрень. Его можно назвать как угодно, CTO, CIO, даже CDO. Будем называть его “Чувак” (пользуясь случаем, передаю привет поклонникам творчества братьев Коэнов). Остаются компании, где Чувака загнали под COO или ещё кого похуже, но это тема для отдельного большого поста (большинство таких компаний в очереди на “цифровую трансформацию” и обречены на появление Чувака непосредственно в executive team).

В софтверной компании Чувак:
- Управляет собственной либо внешней разработкой - чтобы у клиентов вовремя оказался софт достаточного качества
- Управляет эксплуатацией для клиентов – чтобы у клиентов всё бесперебойно работало
- Управляет эксплуатацией для сотрудников – чтобы у сотрудников всё бесперебойно работало

Эти группы задач как правило сильно взаимосвязаны, поэтому разделение этих направлений внутри executive team между несколькими людьми чревато размытой ответственностью и потерей скорости разработки и качества продукта. Бывают вариации в очень больших компаниях, но таких меньшинство.

Применив метод пристального всматривания в задачи Чувака, можно сделать простые выводы. Первое: никуда не уйти от эксплуатации, её может быть очень много. Поэтому идеален Чувак с релевантным опытом. Короче, “админ”. Однако главный вопрос, который кардинально меняет роль Чувака и требования к нему кроется в пропорции между собственным и внешним производством. Если мы не производим сами, а всё закупаем у подрядчиков и вендоров – нам нужен человек, успешно управляющий портфелем проектов и внедряющий их. Снова “админ”. Так вот “админ” – это CIO. Если в компании нет (или немного) собственной разработки, то Чувак скорее всего будет называться CIO (или ИТ-директор), и его главная задача будет обеспечить бизнес “айтишной хренью”. Открыть/Комментировать

2020-05-05 13:34:07 CTO не CTO - II

В прошлом посте мы дошли до базовых показателей опыта CTO – Product Fit, Impact, Budget и Headcount. Всё так или иначе функция масштаба. Первые три показателя очень важные, но они растут вместе с масштабом проекта плавно. Вот твой условный “портфель”, вот он всё тяжелее, больше сложность, бюджеты и ответственность. Но главное в масштабе - в количестве людей, с которыми приходится работать, и в сложности позиций внутри твоей команды. Это меняется с масштабом принципиально.

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

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

Рост компании приводит к перестроению, “бифуркациям” структуры, толкает руководителей к переходу между уровнями, и это часто сопровождается серьезными кризисами в организации. При росте именно CEO и CTO продуктовой компании чаще всего испытывают ломки от перехода на следующий уровень.

Некоторые CEO всячески избегают перехода на более “сложные” уровни организации, принципиально стараются быть маленькими, и не расти выше определенного размера. А когда этот переход становится неизбежным, всегда можно обозвать все свалившиеся задачи “операционкой” и скинуть их на кого-то – на COO, финансового, административного, даже на главу юридического департамента. Это работает, правда, успех сильно зависит от мастерства найти баланс полномочий, иначе будут “перекосы” и организационный долг. Но CTO не CEO, так легко не отделается: придётся органически расти вместе с компанией.

Если вам настолько посчастливилось, что ваш проект со страшной скоростью растет, но вы чувствуете, что “разрываетесь” – посмотрите на описание уровней. Вполне возможно, ситуация объективно толкает вас к очередному переходу, но вы этого не видите, поскольку привыкли жить в прежней парадигме. Не беда, через это проходят все. Меняйте структуру, если нужно, меняйте процессы и людей, действуйте. Если вы находитесь в более "спокойном" режиме, но хотите дальше строить карьеру CTO - расширяйте “портфель” и зоны ответственности, и вся прелесть управления большими коллективами не заставит себя ждать. Если же для дальнейшего роста необходима смена работы - помните, что вам нужно удачно продать текущий опыт. Ключевым вопросом, который показывает уровень управленческой сложности, является вопрос “опишите вашу команду, и как вы с ней работаете”. Подумайте хорошенько, что на него отвечать. Открыть/Комментировать

2020-04-30 11:49:28 Про React

Разбавим занудную хрень вот такими размышлениями о технологиях. В мобилах творится жуткая неразбериха из-за борьбы гигантов, каждый из которых тянет одеяло на себя. До недавнего времени нужно было аж 3 аппа (iOS, Android, WP), сейчас два (WP всё), но до сих пор вот эти два мира - Android и iOS - они настолько разные, что это приводит к тупому удвоению любых, простите, ресурсов на разработку. Естественно, любая попытка изобрести какой-то универсальный способ пилить сразу и Andoid и iOS, привлекает именно снижением этих, извините, издержек. React был одной из таких подающих надежды технологий.

Мне вчера позвонил парень, с которым мы едва знакомы – вместе были на коротком сплаве в Черногории. Они продали свою студию разработки, сейчас он ищет новые ниши, отговаривал его от дейтинга. Короче, расспросил его про тренды у аутсорсеров и про React, потому что у них как раз была на нём специализация.

Почему спросил: Facebook Messenger в последнее время стал ну сильно быстрее (реально нет желания мгновенно перевести диалог в WA или TG). И совсем недавно была большая статья о том, как Facebook Messenger не то отказался от React, не то не выбрал React – несмотря на то, что FB их alma mater. Короче, мне было интересно, как вообще глобально, в тренде React или нет. Выяснилось, что буквально за последний год от React отказались многие компании, через которые он “продавался” аутсорсерами.

Посудите сами:
- Facebook Messenger, совсем свежая мартовская статья: https://engineering.fb.com/data-infrastructure/messenger/. Полит-корректно не используют даже слово React, но там всё сквозит от “using the native OS wherever possible” до “native frameworks don’t have to be translated into sub-frameworks”)
- AirBnB нечего бояться кого-то обидеть, они расписали всё в подробностях: https://softwareengineeringdaily.com/2018/09/24/show-summary-react-native-at-airbnb/.
– по слухам Instagram тоже отказался от Reaсt, но я не могу найти ни подтверждения, ни опровержения.

Основной посыл у всех понятный – скорость/UX, никто не готов этим жертвовать. Вот такая история. Похоже, пилить сразу оба мобильных аппа - всё ещё нерешаемая задачка. Осталось следить за Flutter. Если у вас есть какие-то инсайды про эти технологии, или вы хотите что-то поправить/добавить – контакты в описании канала, если я где-то сообщил неточную/недостаточную информацию – welcome, опубликую. Открыть/Комментировать

2020-04-29 14:08:47 CTO не CTO - I

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

Вместе с карьерным ростом важность вашего технического опыта уходит на второй план. Во-первых, вас наймет CEO, который в этом ничего не понимает, и не должен понимать. Во-вторых, самое главное для достижения результатов – качество команды, а не ваш технический бэкграунд. Соберёте/удержите хорошую команду – будет результат. Тут можно долго спорить о hands on, о важности бэкграунда для продуктовой разработки – это всё понятно, за технологиями надо следить, будем считать, этот опыт есть у всех. Не это будет основными disruptors, определяющими качествами. Грубо я сформулировал для себя 4 базовых не-технических показателя, по которым можно “разложить” CTO:
- Product Fit – что ты делаешь, что за сектор, сколько юзеров и денег
- Impact – ты строишь компанию вместе с executive team или занимаешься только инфраструктурой и IT-проектами
- Budget – размер бюджета, которым ты управляешь
- Headcount – общее число людей во всех твоих командах

Ну и если рассматривать вопрос о “соответствии” конкретным позициям, то сюда безусловно нужно добавить Culture fit, соответствие культурному “базису” компании. Важно: я не претендую на “полноту” или на какой-то конечный фреймворк для оценки, и если вам эта тема интересна глубже с позиций CEO/HRD – позже напишу, что можно посмотреть.

В следующих постах посмотрим, что из этого более важное, а что менее; для компаний на каких этапах развития; и почему скучный Headcount часто оказывается чуть ли не самым критичным показателем. Открыть/Комментировать

2020-04-24 13:48:49 Базовые ценности разработки

Давайте воспользуемся практикой first principal thinking, о которой я написал в предыдущем посте, и “академичненько” разложим кое-что.

Когда разработка Badoo разрослась до сотен человек разных культур и национальностей, мы решили, что пора нам уже зафиксировать наш инженерный культурный код в принципах, ответить на вопросы “кто мы”, “что для нас важно” и “как мы работаем”.

И в первом приближении мы решили, что для нас важно всего три вещи: Delivery (поставка), Quality (качество) и Retention (удержание). Эти принципы были впервые сформулированы в мобильной разработке, и кажется, они не доехали в корпоративные handbook’и в таком же лаконичном виде. Но долгое время они были нашими неформальными ценностями - из-за своей простоты, полноты и измеряемости. Давайте я их поясню:
* Delivery - это доставка продукта, базовой ценности для пользователей, всегда стоит на первом месте. “Move fast”. Быстрый или мертвый. Это главное мотто стартапа.
* Quality - качество, но важно, что оно идёт после Delivery. “Move fast, break things”. Ломай, но чини быстро. Автоматизируй тесты, выкладку, диагностику и откат. Мониторь бизнес-метрики.
* A Retention - это не удержание пользователей, а удержание сотрудников (считаем, что удержание пользователей сидит в Delivery).

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

А теперь посмотрим на другой базис: commitment (обязательство), courage (мужество), focus (фокус), openness (открытость) и respect (уважение). Какая прелесть! Неизмеряемая, идеологическая муть. Вы спросите: где результат, где поставка ценности? И будете совершенно правы. Это - хороший пример смещённых, не самых удачных первопринципов. Не успели, но в следующий спринт – обязательно! Зато бодро, по-пионерски, с courage, focus, openness и respect.

Спасибо, вы только что прослушали вероятно самое "формальное" доказательство популярного в стартаперских кругах утверждения “говно этот ваш Scrum”. Можете обвинить меня в подмене: принципы фреймворка сравниваются с достаточно широкими принципами разработки. Добавь к ним адаптивность продукта и монетизацию - и получишь отличные принципы вообще для всей компании. Но нет, позволю себе настаивать, что это реальные, настоящие, непротиворечивые, базовые принципы разработки. В этом и состоит прелесть хорошего базиса - он полон, не противоречив и легко запоминается. А ценности Scrum - узкие, в них “потеряны” базовые ценности. В Scrum есть ряд полезных практик, но именно эта кособокость, нестройность и куча процессных ограничений приводят на практике к куче проблем. Но это всё отдельные большие темы, и мы ещё “поездим” по скраму неоднократно. Открыть/Комментировать

2020-04-24 13:44:58 Первопринципы

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

По-английски это называется “first principles”. В широком смысле – это набор аксиоматических ценностей, на базе которых выводится логически целостное описание системы. В русском языке нет аналогичного устойчивого выражения, я буду использовать термин “первопринципы” как “основа”, “начала”, “базис рассуждений”, отбросив интеллектуальные лабиринты философии, где этот термин встречается чаще всего.

Удачно сформулированы первопринципы - система удачная, и наоборот. First principles thinking практикуется в продуктовой разработке и вообще при решении творческих задач, когда нужно на старую проблему посмотреть свежим взглядом, спуститься “вниз” до фундаментальных, не выводимых ниоткуда принципов, и вернутся назад к конечной системе, по шагам выстраивая наиболее удачный дизайн через сравнение вариантов, словно математически “выводя” решение. Это всё хуйня, конечно, и обычно люди так думают редко, но так или иначе любой сценарий “улучшения” системы можно представить именно как последовательность “спуска” до первопричин и построения системы заново. Не понту ради, а токмо полноты картины для тут можно вспомнить ТРИЗ (Теорию Решения Изобретательских Задач). Несмотря на свою мутность, эта теория содержит ряд простых и удобных концепций, самый базовый из которых – принцип изобретательского мышления: выявить противоречие, углубиться до первопричин, устранить противоречие, вернуться к улучшенному решению. Это и есть переосмысление системы через фундаментальные первопринципы.

В пример часто приводят SpaceX Илона Маска, где цепочка производства космических ракет была значительно переработана, что привело к более эффективному и значительно менее дорогому решению. Уже не так важно, насколько это правда или красивая легенда. Важно, что вопросы “В чём мы уверены абсолютно точно?” и “Что из этого следует” образуют хороший фреймворк для решения творческих задач. Мы воспользуемся этим фреймворком в следующем посте в достаточно неожиданном, но важном контексте. Открыть/Комментировать

2020-04-23 15:51:09 О себе

Привет! Давайте познакомимся. Я – Алексей Рыбак, CTO в агрегаторе такси “Везёт”. Мой опыт - 20+ лет, из которых больше половины я проработал в Мамбе и Badoo, пройдя путь от руководителя отдела разработки гаражного стартапа до главы разработки миллиардной компании.

Буду писать про управление разработкой в продуктовых компаниях. Чтоб вы понимали, первые темы: “Первопринципы”, “Базовые ценности разработки”, “CTO и CIO”, “CTO не CTO”, “Продуктовая разработка”, “Инженерная культура”, “Дано всё что есть”, “Организация как система”, “Ограничения роста”, “Задачи CTO в растущей компании”, “Автономность и слабая связанность”, “Владение, ответственность и подотчетность”, “Переключение ответственности”, “Пинг-понг задачей”, “Роль тим-лида”, “Тим-лид и Тех-лид”, “Типичные ошибки тим-лидов”, “Скучающий директор”, “Бинарное мышление и нелинейность”, “Адаптивность”, “Шаблонное мышление”, “GTD и SMART-целеполагание”, “МКАП/DISC/PAEI-типологии”. Также обязательно пройдемся по топ булшит-темам десятилетия: “Highload” (не существует), “Микросервисы” (не помогут), “work-life balance” (забудьте), “DevOps” (мешанина) и “Scrum” (не работает).

C удовольствием вступлю в конструктивную полемику или помогу советом – пишите в телеграм @alexeyrybak или на почту alexey.rybak@gmail.com. Открыть/Комментировать