Мобильный Финтех – Кирилл Маканков

В этот раз добавилось сразу 6 новых тем и ближайщие планы были немного реорганизованы:
1. Решил подробнее рассказать, какие практики помогают на этапе бурного роста: Синергия, жесткая фокусировка, несколько разных способов решения одной задачи одновременно, распараллеливание задач и "критический путь", запрет разработчикам ошибаться :), нетерпимость к "замазыванию" последствий и неустранению глубинных причин, повышение эффектиности в красткосрочной перспективе (А-функция)...
2. Чем заняться лидеру при 100% децентрализации?
3. Почему ИИ не грозит джунам
4. SPI: Software Process Improvement («Жемчужины разработки», Карла Вигерса)
5. Добавился пост-ответ на вопрос подписчика, что делать, когда акт делегирования провалился.
6. Обучение взрослых-экспертов

Число постов достигло почти 7 десятков. Круть! 😎
Пишите в комментариях или в личку, о каких темах вам интереснее было бы поговорить вперёд.

Дорожная карта

Привет, друзья!

Этот пост — динамическое оглавление канала. Здесь будут собираться ссылки на ключевые публикации, сгруппированные по темам. Со временем он превратится в удобный навигатор: вы сможете быстро найти материал по интересующей вас теме, не пролистывая всю ленту канала.

1. Инструменты ретроспективы
2. Стартовая точка ( STAR, «Младенчество», P-e-)
3. 20% технического времени: как не превратить инвестиции в потери (EI)
4. Core‑команды — миф о супергероях в разработке (EI)
5. Core-команды: оберег
🪬 от решения ваших проблем (EI)
6. Технический долг как симптом болезни: диагноз и лечение (PAI)
7. О вреде рефакторинга и сокращении его необходимости
(Вопрос-ответ, PAI)
8. Лучшие практики по миграции с ObjC на Swift (PAI)
9. Модуляризация – локализация изменений (PAI)
10. Дух стартапа в Энтерпрайзе: плюсы модуляризации (AI)
11. Как модуляризация укрощает хаос связей: от экспоненты к линейности (AI)
12. Неудачная модуляризация (STAR)
13. Сложности модуляризации и их решения (PAI)
14. Экстенсивный vs интенсивный (PAI)
15. Взрывной рост и текучка (STAR, «Давай-давай», PaEi, проблемы этапа и пути их решения)
16. Институционализация Е-функции (АI)
17. Доверие (I)
18. Презумпция профессионализма (I)
19. Ставка на рост: джуны вместо A+ (I)
20. Синергия и фокусировка (PI)
21. Единственное решение — путь к провалу (PAI)
22. Как поступать, если акт делегирования провалился — (A)
23. Распараллеливание задач и критичный путь (PAI, «Мифический человеко-месяц» Фредерика Брукса «Совершенный софт» Джувела Лёве)
24. Модульные тесты (PAI)
25. Принципы FIRST (PA)
26. Обучение взрослых-экспертов (AI)
27. Не позволяй разработчикам ошибаться — (AI)
28. Нетерпимость к «замазыванию» последствий и неустранению глубинных причин - (PA)
29. Повышение эффективности в краткосрочной перспективе (A-функция)
30. Чем заняться лидеру при 100% децентрализации?
31. Организация процесса («Юность», код, pAEi?)
32. Исчерпывающая документация (A)
33. Стандартизация практик разработки (A)
34. Шаблоны проектирования (AI)
35. Переиспользуй это! (PA)
36. Пилоты/эксперименты/PoC — (E)
37. MVP и PoC— выкинуть или рефакторить? (AI)
38. Обратимые и необратимые изменения - (I)
39. Сложности внедрения — (I)
40. Автоматизация процесса — (AI)
41. Формирование Цели и Стратегии подразделения — (I)
42. Франшиза?
43. "Расцвет" по Адизесу
44. Избегание ненужных работ — (I)
45. Святое импортозамещение — (I)
46. Вверх по пирамиде тестирования: скриншот- и интеграционные тесты — (PAI)
47. Мультирезпозиторий против монорепозитория – (PAI)
48. Сокращение времени регресса — (AI)
49. Метрики — (AI)
50. Результаты
51. Невероятные X10-программисты и где они обитают
52. Оптимизации
53. Апгрейд дизайн системы - (EI)
54. Автогенерация кода vs шаблонный код - (AI)
55. Безопасность — (I)
56. Неудачи?
57. "Поздний расцвет", "Старение", сокращения штата
58. О святой вере в научный метод
59. Искусство vs ремесло
60. Как читать книги? (AI)
61. Что дальше?
62. Дашборд.
63. Развитие доверия, уважения и принадлежности — (I)
64. Эволюционная архитектура? — (PAEI)
65. Омниканальность? (PEI)
66. Искусственный интеллект - (PAEI)
67. Почему ИИ не грозит джунам
68. SPI: Software Process Improvement («Жемчужины разработки», Карла Вигерса)
69. Экономия на внутренней интеграции (I)
70. Личные выводы: Что я приобрёл? Чем горжусь?
71. …

Пишите мне, какие темы добавить в дорожную карту — я учту ваши пожелания при планировании контента!

Ставка на рост: джуны вместо A+

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

Сегодня – о том, кого стоит нанимать к вам в подразделение на этапе «Давай-давай» по Адизесу.

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

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

Адизес в книге «Управление жизненным циклом компании» «обнаружил, что лидеры аномальных компаний, достигших данного этапа осуществляют дополнительные выплаты своим подчиненным, как бы покупая их согласие со своими действиями». Мы тоже этим грешили, учитывая уровень зарплат специалистов A+. Но нам это не помогло: такие специалисты к нам не особо шли, а те, кто пришёл, в итоге уходили.

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

Удивительно, но это сработало. Позже я нашел у Адизеса объяснение этому: на этапе «Давай-давай» компании организуются вокруг людей, а не ролей. Часто один сотрудник закрывает сразу несколько направлений: «Например, один известный мне президент компании возглавлял отдел закупок, отдел сбыта и конструкторский отдел. Работники отдела сбыта осуществляли также некоторые закупки, а бухгалтер время от времени подменял офис-менеджера». В таких условиях люди чувствуют свою ценность и незаменимость, даже не являясь экспертами в каждой из задач. Они готовы учиться и развиваться в любом деле, которым занимаются. Это как раз про джунов и мидлов: климат этапа «Давай-давай» им идеально подходит.

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

Вывод простой:

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

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

Не переключайтесь!