Java Month: участвуйте в событиях и получите возможность выиграть суперприз! 🎁
Узнать больше
06.07.2022
9 минут чтения

Проблемы роста IT компаний

Сергей Немчинский

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

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

Проблемы менеджмента

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

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

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

Проблемы информации

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

Так же, представьте ситуацию с набором большого количества новых сотрудников. Программисты — не самые контактные люди. Естественно, представление о программисте, как о тощем волосатом социофобе несколько (хм..) неверно. Но все равно, особенность нашей работы состоит в том, что мы много времени проводим в размышлениях и соответственно — не самые контактные люди. По крайней мере —в массе. И в ситуации, когда человек постоянно видит вокруг себя новые лица и даже не знает примерно — кто это такие, ему становится дискомфортно. И вопрос социализации новых сотрудников в старых отделах и старых сотрудников в новых отделах необходимо решать комплексно. Возможно, не стоит водить каждого сотрудника за ручку по всему офису (хотя, французы, например, так и делают — сам видел), все-таки в нашем менталитете это воспринимается самим человеком несколько … ну, не то чтобы унизительно, но близко к тому. Однако познакомить человека хотя бы с его непосредственной командой и с соседями по офису — стоит. Это необходимо для того, чтобы весь рабочий коллектив чувствовал себя именно коллективом, а не случайными попутчиками в электричке.

Старички и новички

В настоящее время сложилась странная практика, когда новых сотрудников нанимают на большую зарплату, чем получают старые сотрудники. И как бы не заставляли фирмы сотрудников скрывать свои зарплаты от коллег, информация все равно выплывает наружу. И естественно мало приятно узнавать, что тебя, который верой и правдой работал на благо своей фирмы несколько лет и неплохо разбирающегося и в предметной области и в особенностях работы именно на этом месте, ценят (а деньги — это же выражение ценности, разве нет?) меньше, чем человека, который ничего в этом не понимает и которого приставили к тебе, чтобы ты его учил. По различным опросам этот фактор служит одной из основных мотиваций для смены работы. Да и отношения внутри коллектива между «старичками» и «новичками» вряд ли становятся настолько близкими, как могли бы. Я понимаю, что большинство IT фирм в Украине — натуральные body shops. То есть чтобы нанять нового человека, нужно подтверждение от заказчика. И на наем новых сто-пятьсот человек дают чохом. А для того, чтобы повысить зарплату конкретному сотруднику необходимо получить это подтверждение индивидуально. И подавляющее большинство менеджеров просто ленятся это сделать. А потом неожиданно теряют ключевых сотрудников в критический момент либо просто и незаметно (а это самое печальное для фирмы) люди работают спустя рукава, так как уверены, что их просто не ценят. Честно скажу, за 15 лет моего стажа программистом, я слышал про регулярные индексации и повышения зарплаты сотрудникам всего пару раз. И это очень грустно. Компании из-за такой необдуманной политики получают отношение к себе сотрудников, как к пересадочной станции.

Проектные риски

Закон Брукса никто не отменял. Если кто забыл, то он звучит так: «привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта». Поэтому надо понимать, что набирать большие стада программистов в момент, когда у вас полная запарка по многим проектам — очень неразумное решение. Лучше всего набирать людей постепенно и исключительно в проекты, которые еще не стартовались, чтобы не создавать ни новым сотрудникам ни менеджменту излишних стрессов. А стресс как известно это отношение количества задач на единицу времени. Больше задач — выше стресс, больше времени — он меньше.

И в заключение

По моим наблюдениям, лучше всего набор большого количества народа проходит в таком формате: в каждой новой команде должен быть как минимум один сотрудник, до того работавший на фирме. Идеально, если это был руководитель команды (тим лидер или ПМ) и желательно еще один рядовой сотрудник. Эти «старички» передадут корпоративную культуру новичкам, уменьшат их стресс от вхождения в новую среду и помогут решить многие бытовые проблемы. Ну и у вас получится на выходе такой же дружный коллектив, как раньше, но больше по численности.

Удачных вам расширений!

Сергей Немчинский
CEO FOXMINDED
Добавить комментарий

Ваш имейл не будет опубликован. Обязательные поля отмечены *

Сохранить моё имя, имейл и адрес сайта в этом браузере для будущих комментариев