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

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

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

2. Близость коммуникаций Работая в небольшом офисе (пусть даже на несколько этажей, но всё в одном здании), общаешься со всеми сразу. Можешь сыграть в настольный теннис с человеком из бизнеса, сходить на обед с ведущим разработчиком, встретить дизайнеров после работы. То есть неформально знаешь всех коллег одновременно. Это опять таки и хорошо, и плохо. Хорошо -можно обсудить что-то и получить информацию напрямую, без нескольких этапов согласований. Не нужно выяснять, кто с кем когда договаривался и кто кому какую задачу поставил. Плохо -то же работает и у других, и ты теряешь погружённость в непосредственный пласт работы. Пропустив одно-два мероприятия, можно упустить договорённость между коллегами. Если есть письменные следы (письма, документы, задачи, артефакты) -восстановить картину можно, если нет - то только разговаривать.

3. Изменчивость окружения В бигтехах Confluence, Jira и десяток других инструментов -данность, устоявшаяся и неизменная. Рабочее место -тоже. В маленьких же компаниях устоявшегося окружения зачастую просто нет: продукты Atlassian, например, стоят дорого и не всегда по карману небольшой команде.

Инструментарий изначально выбирает бизнес -то, что ему ближе, проще и дешевле. А дальше он меняется в процессе, иногда не раз: то не устраивает разработку, то не поддерживает версионирование документации -причин масса. В бигтехе сложно представить ситуацию, где тебе говорят: “Улучши флоу создания документации” -и ты сам заменяешь и внедряешь новое решение. В небольшой компании это было. Если будет интересно -расскажу отдельно, как именно я это решил, что выбрал и почему.

4. Скорость решений Спойлер: не всегда то, что меня устраивает. Но скорость в маленьких компаниях правда колоссальная: бизнес сказал “подумаем” -ты успел сходить на обед -а тебе уже несут ответ. Плюс в том, что архитектурное или аналитическое решение достаточно показать одному человеку -и можно запускать в разработку. Минус -далеко не все решения, принятые за пять минут, оказываются верными для бизнеса. Иногда лишнее обсуждение, показ ещё одному лиду фронта, бэка или мобайла, спасают от кучи ошибок, переделок и откатов с прода. Это же касается и мобильности в широком смысле: можно прийти на следующий день и узнать, что вас пересадили в другой кабинет, или что переезжаете в другое здание (никто не объяснит зачем), или что руководство решило переехать куда-нибудь в Узбекистан -и если хочешь остаться в компании, готовься к релокации. Вывод Можно долго рассуждать, где работать лучше -в бигтехе или в маленькой растущей компании. Однозначного ответа нет, это просто разный опыт. В небольшом коллективе твои решения реально влияют на процесс -ты можешь влиять на то, в какую сторону движется корабль. Но чем он меньше, тем больше на тебя влияют подводные камни, которые, может, в большом корабле и не заметил бы.