Intro

Всем привет!

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

Меня зовут Дима и сейчас я работаю в достаточно крупной prop-tech компании на позиции CTO.

В данный момент я занимаюсь внутренними продуктами, которые помогают организовать, автоматизировать и улучшить HR процессы и EJM (о том, что это такое, я тоже как-нибудь расскажу).

До этого я долго работал в международных командах на позициях начиная от senior developer и заканчивая principal developer / individual contributor.

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

Я хочу постараться систематизировать свой опыт и получить обратную связь, научившись новому от людей, читающих этот канал - поэтому буду рад любым комментариям, вопросам и обсуждениям :)

О чем буду писать:

- о найме и удержании технических команд
- об IT продуктах
- о scrum и agile
- о культуре внутри компании
- о своем личном восприятии такой противоречивой роли как «CTO»
- да и в целом об IT

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

🤘

Кем ты стал? Путь самурая технического менеджера

Первую серию постов я решил посветить карьерному треку engineering manager (о том, что такое карьерные треки и какие варианты развития я вижу именно в технических командах, я расскажу позже).

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

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

Я планирую написать несколько постов на данную тему для каждого временного промежутка и этапа своего роста:

- Teamlead
- Engineering Lead
- CTO

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

See ya.

Кем ты стал? Teamlead. Часть 1

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

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

Это достаточно губительный для команды и компании подход по двум причинам:
- компания теряет хороших разработчиков
- компания не получает хороших руководителей

Надеюсь, в твоей компании все не так, и ты попал на роль тимлида, потому что ты реально хочешь в лучшую сторону изменить процессы в своей команде (а может и во всей компании), тебе интересен профессиональный и карьерный рост людей вокруг себя, управление ресурсами в разработке, создание классного климата в своей команде. Ведь именно этим тебе и придется заниматься 70% своего времени. Добавь сюда стандартную историю про найм/повышения/увольнения.

Теперь осмотрись вокруг - оцени размер своей команды и размер компании в целом. От этого многое зависит. Ведь именно от зрелости компании и команды зависит то, на чем тебе придется фокусироваться в первую очередь.

Если мы говорим про компанию, находящуюся на этапе активного роста (например ты попал в стартап, который недавно поднял раунд инвестиций), то твоими приоритетами будут:

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

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

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

И в том и в другом случае, тимлид - это на 70% "софтовая" роль, по крайней мере судя по моему опыту. Есть, конечно, рок-звезды, которые умеют и в код, и в менеджмент, но таких на рынке меньшинство.

Со своей стороны всем, кто хочет стать (или уже стал) тимлидом, могу дать пару-тройку советов:

- Документируй и описывай процессы. Создавай базу знаний для своей команды, чтобы при агрессивном росте не нужно было постоянно объяснять одно и то же на onboarding-сессиях для новых сотрудников, у тебя точно не будет на это лишнего времени.
- Если не получается быстро найти senior-разработчиков, бери middle+. Их сильно больше на рынке, а если у тебя в команде классные задачи, через полгода-год они потянут senior уровень.
- Всегда ищи win-win решения в отношениях с внутренними заказчиками/стейкхолдерами. Это очень пригодится тебе в будущем. Защищай свою команду, но и не забывай об интересах бизнеса, ведь иначе на роли тимлида в скором времени окажется кто-то более лояльный :)

Минутка рефлексии. Приоритеты и принципы

Вся соль работы на позиции типа CTO, это то что ты должен постоянно находиться в trade-off состоянии с бизнесом. Вечный поиск компромисса, переговоры и перебарывания себя и коллег :)

Летом я был на классном кэмпе, который устраивали компании из большой пятерки в ИТ.
Так вот, Эмиль Абдулнасыров (CTO @ Lamoda), в одном из докладов высказал интересную идею о том, что важно выявить для себя 3-5 стратегических принципов, которые ты, как управленец, в любой ситуации будешь защищать в переговорах с коллегами из бизнеса, с внутренними стейкхолдерами, смежными командами и т.д.

Это помогает не распыляться и не тратить свою энергию на менее важные вещи, тем более без торга все равно не получится - что-то защищаем, а что-то готовы обсуждать.

Для себя я сформулировал 3 основных принципа, которые я стараюсь защищать в коммуникациях с коллегами/заказчиками/бизнесом:

- Технологический стек. Мне важно, чтобы у меня в команде не было зоопарка и мы не тратили бы лишний человеческий ресурс на сопровождение разнородных продуктов. Исключение - это вендор решения, но их мы стараемся максимально интегрировать в процессы компании (CI/CD, деплоймент и т.д.).

- Команда. В любой ситуации я стараюсь прежде всего помнить об интересах команды - стратегически я не приемлю овертаймы и в целом не поощряю это в команде. Потому что переработки и неадекватный график в любом случае выходят боком на дальней дистанции, а вы получаете звание "человека, который загнал команду" (а для С-Level позиций этот статус обычно сохраняется даже после выхода из компании).

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

Иногда бывает тяжеловато отстаивать свои границы, но с другой стороны, все мы любим челленджи :)

Кстати вот ссылка на сам доклад, очень советую ознакомиться

Кем ты стал? Teamlead. Часть 2

Первый пост на эту тему чуть выше.

Задумался тут недавно, чем крутые команды отличаются от обычных.

На ум сразу приходят механические штуки типа velocity, cycle time и прочих метрик, которые, в целом, достаточно легко исказить или подчинить себе, а потом представить в выгодном для себя свете. Мол, у крутых команд velocity выше, да и вообще графики в JIRA более красивые.
При этом давайте сразу определим - в умелых и честных руках это реально классные инструменты, которые позволяют улучшить и настроить процессы внутри команд.

Мне вот кажется, что крутость команды определяется количеством людей со взрослыми позициями внутри нее.
Причем "взрослость" позиции определяется такими качествами как:

- Вовремя видеть проблему и, при необходимости, просить помощь
- Адекватно оценивать свое состояние и силы
- Проявлять инициативу, не ждать пока за тебя её проявит кто-то более "взрослый"
- Уметь договариваться
- Уметь адекватно челленджить решения коллег

+ еще с десяток других "софтов", которые сейчас становятся важнее "хардов".

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

В общем, это я к тому, что прокачивание вот этих сильных сторон в команде, это и есть одна из основных функций тимлидов.

Желаю всем поработать в таких командах :)

Техдолг

На днях осознал, что ровно в тот момент, когда компания принимает решение называть себя технологической (читай, добавляет себе суффикс "tech"), она автоматически принимает тот факт, что технический (а вообще даже технологический) долг нельзя игнорировать.

Имея хреновые процессы по работе с техдолгом, игнорируя его, думая только о feature-бэклоге, компания уже через пару месяцев начнет стагнировать в плане экспертизы разработки и качества продуктов.

Это же касается архитектурного долга (катим в прод временные решения и забиваем на их эволюцию).
Туда же идет аналитический долг (зачем нам описание в задачах и документация, мы же уже все обсудили на созвоне с разработкой).
И так далее.

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

Выше я уже обозначил свои основные принципы, среди которых как раз есть отвлечение ресурсов от feature-бэклога. А вот теперь у меня это состыковалось с "другой стороной". Я понял, что не только я должен отстаивать эту часть процессов, но и бизнес (а в идеале топ-менеджмент компании) должен понимать и принимать её ценность уже на начальном этапе. Более того, технический менеджмент вполне вправе требовать это от бизнеса, если этот бизнес существует с суффиксом "tech".

Такие дела.

On-Prem vs SaaS

В последнее время начал думать о том, как выводить продукты на рынок. А это ведь достаточно сложная история:

- Надо понять какими силами это делать, но при этом доп. косты должны быть минимальны.
- Надо узнать, что нужно рынку и кто вообще твой покупатель - малый, средний, крупный бизнес.
- Надо исследовать клиентский путь, а из этого сформировать УТП и вообще понять как с клиентами взаимодействовать при продажах.
- Надо, наконец, выбрать между SaaS или On-Premise моделями, а сразу оба варианта охватить нереально т.к. они очень сильно отличаются технически.

Мне душой сильно хочется в SaaS, т.к. сильно не хочется вникать в инфраструктуру клиентов и тратить много ресурсов на внедрение. Однако все таки нашел для себя нормальные варианты On-Premise:

- Даже если клиент хочет свою инфраструктуру, она необязательно должна быть на базе bare-metal, можно организовать ее в managed облаке, а это сразу срежет мои косты на внедрение и настройку (жаль нет AWS, но в Yandex/VK cloud тоже все достаточно неплохо).
- Если клиент не хочет облако и принципиально хочет разворачивать решения на базе bare-metal, тогда можно попробовать запартнерится с каким-нибудь ИТ интегратором, который и железо клиенту поставит, и софт при необходимости настроит.

Чего точно не хотелось бы, так это идти в историю, где у клиента уже существует ИТ низкого уровня (свое или в аутсорсе). Вот сюда точно придется сливать много энергии и ресурса.

В общем, вот такие мысли по On-Premise. Буду думать.

Цели и стратегия

На прошлой недели у нас в команде состоялась стратегическая сессия для подведения итогов 2023 и планирования 2024 года. 2 встречи по 4 часа с ключевыми лидерами команды, владельцами продуктов и т.д.

Я получил вопросы сразу от нескольких разработчиков по поводу того, зачем это нужно, ведь цели можно сформулировать и в моменте. Да и по факту, то что ты можешь планировать в начале года, может стать неактуальным уже через пару месяцев (ушел важный вендор, поменялись бизнес-требования и т.д.).

Возможно, планирование и стратегия действительно не супер важны для маленьких команд (к примеру до 10 человек) - ведь в таких условиях вы все можете обговорить на звонке в моменте, да и коммуникации в таких командах требуется в разы меньше, чем в командах из 100+ человек.

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

- Хотим иметь superapp к концу года? Значит надо выровнять команды в плане технологий и сроков для его реализации
- Хотим чтобы продукты стали быстрее на 20%? Значит надо реализовать инструменты для измерения, найти узкие места, поставить задачи на их оптимизацию и проверить эффект
- И так далее

И это все не делается за месяц, если у тебя 20+ продуктов. Добавим сюда бизнесовые роадмапы по продуктам и их сроки/приоритеты. Если ничего не планировать, то я вижу 3 варианта развития событий:

- Работа не будет сделана
- Работа будет сделана, но команда зашьется
- Получим вообще не то, что хотим

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

Зона комфорта

Так уж сложилось что я не часто выхожу из зоны комфорта в плане работы. За все время (а это больше 12 лет) было буквально 4-5 раз, когда мне сильно приходилось перестраиваться в плане моего скиллсета и подходов:

- когда решил кардинально сменить стек с PHP на Python 10 лет назад
- когда взял первый кастомный большой заказ как фрилансер
- когда активно начинал работать с иностранными заказчиками и в спешке доучивал разговорный английский
- когда запускал большую hr платформу с почти нулевым ресурсом
- когда занял роль тех. директора и пришлось учиться договариваться не только с командой, но и с бизнесом

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

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

Кто такой senior?

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

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

Теперь, когда лидеров достаточно, я пришел к мысли, что важное качество для синьоров - иметь взрослую позицию и в целом развить в себе ответственность за продукт (так называемое accountability).

Банальные и простые примеры из практики:

- Найти best practice для написания тестов в продукте и самому предложить в качестве улучшения, вместо того, чтобы ждать этого от руководителя разработки

- Увидеть медленный endpoint в API и создать задачку в техдолге, а не мириться со страданиями юзеров

- Заметить отсутствие комментариев в коде и добавить их в своем следующем merge request-e

Для команды понятным примером будет аналогия с походом в лес - после нас лес всегда должен остаться чище, чем до нас :) только в нашем случае лес - это исходный код, документация, дизайн макет, таск трекер и так далее

Системный дизайн и архитектура

Не уверен что это хорошая тема для утра воскресенья :)

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

Вчера досмотрел классное интервью по системному дизайну, которое проводил Александр Поломодов (СТО @ Тинькофф), а мне в команду как раз нужен ведущий системный архитектор. В этом интервью разбиралась система букинга отелей с перспективой на высокие нагрузки.

Для себя выделил важные этапы для такого типа собесов, которые помогут нанять классного специалиста:

- Верхнеуровневый дизайн системы (big picture). Здесь проверяем какие основные движущиеся части системы выделяет кандидат
- Выбор оптимальных технологий для каждой из частей. Например, где стоит использовать nosql решение, а где реляционную БД, в какой ситуации нужен шардинг и как он будет разделять данные по шардам в этом конкретном случае
- Какой транспорт и контракты лучше настроить между частями системы
- Частные кейсы в этой предметной области. Например, как реализовать овербукинг
- Критические штуки типа идемпотентности запросов на платежном API (чтобы случайно не забукать несколько номеров при потере связи)

Для своих собесов я эту задачу использовать не буду, конечно :) Но скорее всего придумаю что-то подобное.

Кем ты стал? Teamlead. Часть 3

Прошлый пост вот здесь.

Наверное, это будет заключительный пост на эту тему, и я хочу посвятить его зонам роста для тимлидов в сторону руководителей разработки (engineering manager).

В моей команде тимлиды это административные руководители, в зоне ответственности которых лежит определенная профессия - backend разработка, frontend разработка, QA, 1C разработка, и так далее.

Функционально они находятся на одном уровне с техлидами, которые определяют сам вектор развития профессии в плане технологий.

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

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

Здесь также начинается история про умение договориться с другими руководителями в рамках своей горизонтали - например с QA, дизайном, продактами и т.д.

Таким образом зоны роста для тимлидов это:

- Развивать технологический кругозор в рамках подконтрольных профессий и не только

- Брать на себя ответственность за результат всей разработки, а не только ее отдельной части

- Уметь в кроссфункциональные процессы (контракты, договоренности между командами и так далее)

- Уметь во внутренний stakeholder management (об этом будет пост чуть позже)

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

Stakeholder Management

Важная часть работы менеджера - это взаимодействие с внешними и внутренними заказчиками/стейкхолдерами.

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

За последние несколько месяцев я пришел к тому, что:

- Нет смысла сливать слишком много энергии и пытаться продавить какие-то свои решения вопреки принятым в компании процессам - обычно здесь возникает слишком много сопротивления, а результат будет все равно не тот, который мне нужен.
- Всегда лучше формализовать взаимодействие с заказчиками - фиксировать договоренности через почту, фиксировать риски, страхуя команду.
- К каждому отдельно взятому стейкхолдеру нужен индивидуальный подход. Заранее подумайте с каким УТП вы пойдете обсуждать проблему и в каком формате вы это будете делать :)

Для того, чтобы упаковать это в некий понятный фреймворк, существует два подхода:

- Stakeholder Mapping - вот здесь можно забрать классный шаблон для Miro и почитать как его использовать. Если кратко, то вам нужно выделить ключевых стейкхолдеров по вашим проектам и продуктам и постепенно добиваться того, чтобы все они оказались в правом верхнем квадранте. Сделать это можно либо повышая их влияние, либо повышая интерес к вашим продуктам.

- Stakeholder Table - вот тут я подготовил шаблон в Google Sheets, который вы можете забрать себе. Здесь вы добавляете ключевых стейкхолдеров, оцениваете их влияние и отношение к вашим продуктам, а дальше система рассчитает итоговые значения. Ваша задача - улучшать взаимодействие с ними так, чтобы все окрашенные колонки приняли зеленый цвет.

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

Кем ты стал? CTO. Часть 1

Наверное, каждый разработчик мечтал о том, что когда-нибудь он станет большим и важным техническим директором и будет вершить судьбы ИТ.

При этом в контекст этой роли часто закладывается только позиция "самого скиллового разработчика". Это действительно бывает так, но только в очень небольших командах, где во главу угла ставится скорость разработки и понимание процессов в ИТ.
С ростом команды трансформируется и роль СТО: постепенно он может превратиться из рок-звезды разработки в IT-партнера для бизнеса, а в каких-то компаниях и в некий коллективный ИТ-разум, состоящий из нескольких людей - ИТ-архитекторов, лидеров разработки и т.д.

Мы в команде активно прорабатываем процессы приземления бизнес-инициатив на конкретные продуктовые направления и команды и стараемся сделать их максимально прозрачными для обеих сторон - от этого сильно зависит комфорт и ИТ-команды и бизнес-заказчиков (выше я уже писал, насколько важно грамотно управлять ожиданиями стейкхолдеров).

Обычно такой процесс представляет собой следующие шаги:

- Заполнение краткого брифа
- Интервью с бизнесом
- Определение направления и приоритета бизнес-инициативы исходя из того эффекта, который окажет ее реализация
- Реализация инициативы на уровне направления - вот здесь подключаются бизнес-аналитики, разработка и тестирование
- Релиз и последующая коммуникация с целевой аудиторией (демо, анонсы, обучения и так далее)
- Сопровождение

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

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

В моем понимании в этом, в том числе, и состоит роль ребят на позициях С-level в большом IT: CPO/CTO/CDO и т.д. Работая в синергии друг с другом можно достигать классных результатов и быть предсказуемыми и понятными для коллег из бизнеса.

Так что, работая на позициях senior/lead разработчиков подумайте, насколько вам это интересно :) Возможно вместо этого есть смысл пойти в "хардовый" трек - стать крутым individual contributor или системным архитектором, благо в крупных ИТ компаниях обычно есть и эти роли.

Контроль качества

Сегодня на 1:1 с одним из лидов разработки рассуждали как обеспечить качество продукта на должном уровне. Сейчас в этой команде есть ощущение, что начали повторяться одни и те же ошибки, а технический долг стал расти и хуже управляться.

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

Баланс между feature-бэклогом и техническими задачами

У нас в команде есть договоренность между бизнесом и разработкой о том, что мы выделяем фиксированную часть емкости продуктовой команды внутри каждого спринта на технические задачи - 20%. Но часто либо сама команда разработки/QA забывает об этом и берет мало технических задач в спринт, либо бизнес приходит с горящими сроками и приходится двигаться.

Здесь каждому важно понять, что работа над тех.долгом это всегда инвестиция в продукт, нет "инвестиций" - рано или поздно придется останавливать feature-разработку и разгребать образовавшееся болотце уже в режиме пожара.

Технический долг всегда будет расти, это можно воспринимать как аксиому - важно им правильно управлять. Технические задачи оборачиваются в технические проекты, которые ведутся точно так же как и бизнесовые - со своими досками, приоритетами, требованиями и так далее. Это делает их сильно прозрачнее не только для команды, но и для бизнеса (а значит их проще обосновать).

Баланс между функциями в команде

Слишком много разработки? QA не будут успевать тестировать все поставляемые фичи и делать полноценный регресс.
Слишком мало аналитики? Нет требований на должном уровне, снова пострадает качество.
Поэтому тимлидам важно работать с ресурсом команды и с ключевыми для них стейкхолдерами (обычно это владельцы продуктов) - вовремя синхронизировать ресурс команды и roadmap продукта, закладывать риски при оценке проектов и так далее.

Баланс между написанием кода и написанием тестов на этот код

Тут не буду долго объяснять, скажу лишь что за 2 года работы на текущей позиции, у нас уже случались достаточно большие рефакторинги внутри продуктов, и если бы не написанные ранее тесты, по срокам они заняли бы раза в 2 больше времени.
Слишком много тестов тоже плохо - тогда команда разработки будет тратить слишком много времени на их поддержку. Оптимальное покрытие, на мой взгляд, это 80-85%.

Вроде очевидные принципы, но не всегда получается им следовать, даже в командах с отстроенными процессами.