Для большинства компаний, которые не собираются всю жизнь сидеть в одной комнате и удовлетворяться заказами от одного единственного заказчика, рано или поздно наступает такой момент, когда пора расширяться. И то, что и наша компания столкнулась с этой проблемой (а наем большого количества новых сотрудников — проблема, знаете ли ) послужило неплохим пинком для того, чтобы сесть и разобраться, чем такое сильное расширение грозит для самой фирмы. Ну и для сотрудников фирмы, конечно, тоже.
Оказалось, что информации о проблеме роста компаний, и даже именно о проблемах роста именно IT компаний — очень много. И я немного пособирал информацию для себя. Ну и заодно решил с вами поделиться.
Проблемы менеджмента
Все компании начинают либо как классические на несколько человек стартапы либо как отколовшийся кусок другой большой компании . Поскольку проблемы все равно похожие небольшая команда единомышленников, в которой каждый «универсальный солдат», готовый и код писать, и с заказчиком договариваться и на установку съездить, и офис подмести, то в такой компании устанавливаются достаточно своеобразные субординационные отношения и естественно, практически отсутствуют принятые процедуры. Все делается как в первый раз. И высока ценность людей, которые могут сделать все, хотя бы даже и не идеально.
По мере роста компании выясняется, что специалисты на все руки все менее востребованы в компании и все более нужны высококлассные специалисты в своих узких областях. Если на этапе стартапа вас вполне устраивало, что у вас один человек и бухгалтерию сводит и с заказчиками переговоры ведет и инвесторов окучивает, то по мере роста становится понятно, что пора бы уже иметь трех разные людей, которые будут делать эти работы одновременно. А потом — и три разные отдела, а может даже и департамента. И выясняется, что универсальные солдаты эпохи стартапа могут уже и не так хорошо справляться с изменившимися требованиями. Раньше человек получал заказы на личной харизме, а теперь ему надо как-то так построить работу отдела продаж, чтобы продукты все равно продавались. Если брать именно программистов, то совсем не факт, что прекрасный и креативный программист будет отличным директором департамента разработки и руководить работой полусотни программистов. То есть с большой долей вероятности вообще не видеть код никогда. А проводить весь рабочий день в совещаниях, документации и основой его рабочего успеха станет не тот самый код, которого он уже не видит, а построенный и отлаженный процесс разработки и сопровождения готового кода. Это, знаете ли, совершенно других умений требует.
И очень часто оказывается, когда один или несколько из основателей компании упираются в свой потолок менеджерских умений, а их фактическая должность требует от них уже гораздо больших умений. И в результате те, кто компанию создал начинают уже тормозить ее развитие. В каждой компании решают такие вопросы индивидуально, но общая тенденция такова, что если таких основателей выкидывают из компании, то оказывается, что компания лишается перспектив роста. Вспомните, например, знаменитый и дико популярный интернет-пейджер ICQ. И где он теперь? Все создатели после продажи компании от туда, насколько я знаю, постепенно ушли и все. Проект уже никому не интересен (а существует ли он еще?). Поэтому требуется как-то так развиваться, ставя на ключевые места нужных специалистов, при этом удерживая дух основателей. Это очень сложно, но одно радует. Это проблемы самого высшего руководства компании, так что я о них больше писать не буду, так как таковым не являюсь.
Проблемы информации
Оказалось, что одним из основных источников проблем в среде компании является отсутствие информации о происходящих событиях. Оказывается, люди больше всего недовольны не плохими событиями или неудобствами, а тем, что они ничего не слышат от руководства об этом. И даже не знают, когда эти неудобства закончатся.
Так же, представьте ситуацию с набором большого количества новых сотрудников. Программисты — не самые контактные люди. Естественно, представление о программисте, как о тощем волосатом социофобе несколько (хм..) неверно. Но все равно, особенность нашей работы состоит в том, что мы много времени проводим в размышлениях и соответственно — не самые контактные люди. По крайней мере —в массе. И в ситуации, когда человек постоянно видит вокруг себя новые лица и даже не знает примерно — кто это такие, ему становится дискомфортно. И вопрос социализации новых сотрудников в старых отделах и старых сотрудников в новых отделах необходимо решать комплексно. Возможно, не стоит водить каждого сотрудника за ручку по всему офису (хотя, французы, например, так и делают — сам видел), все-таки в нашем менталитете это воспринимается самим человеком несколько … ну, не то чтобы унизительно, но близко к тому. Однако познакомить человека хотя бы с его непосредственной командой и с соседями по офису — стоит. Это необходимо для того, чтобы весь рабочий коллектив чувствовал себя именно коллективом, а не случайными попутчиками в электричке.
Старички и новички
В настоящее время сложилась странная практика, когда новых сотрудников нанимают на большую зарплату, чем получают старые сотрудники. И как бы не заставляли фирмы сотрудников скрывать свои зарплаты от коллег, информация все равно выплывает наружу. И естественно мало приятно узнавать, что тебя, который верой и правдой работал на благо своей фирмы несколько лет и неплохо разбирающегося и в предметной области и в особенностях работы именно на этом месте, ценят (а деньги — это же выражение ценности, разве нет?) меньше, чем человека, который ничего в этом не понимает и которого приставили к тебе, чтобы ты его учил. По различным опросам этот фактор служит одной из основных мотиваций для смены работы. Да и отношения внутри коллектива между «старичками» и «новичками» вряд ли становятся настолько близкими, как могли бы. Я понимаю, что большинство IT фирм в Украине — натуральные body shops. То есть чтобы нанять нового человека, нужно подтверждение от заказчика. И на наем новых сто-пятьсот человек дают чохом. А для того, чтобы повысить зарплату конкретному сотруднику необходимо получить это подтверждение индивидуально. И подавляющее большинство менеджеров просто ленятся это сделать. А потом неожиданно теряют ключевых сотрудников в критический момент либо просто и незаметно (а это самое печальное для фирмы) люди работают спустя рукава, так как уверены, что их просто не ценят. Честно скажу, за 15 лет моего стажа программистом, я слышал про регулярные индексации и повышения зарплаты сотрудникам всего пару раз. И это очень грустно. Компании из-за такой необдуманной политики получают отношение к себе сотрудников, как к пересадочной станции.
Проектные риски
Закон Брукса никто не отменял. Если кто забыл, то он звучит так: «привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта». Поэтому надо понимать, что набирать большие стада программистов в момент, когда у вас полная запарка по многим проектам — очень неразумное решение. Лучше всего набирать людей постепенно и исключительно в проекты, которые еще не стартовались, чтобы не создавать ни новым сотрудникам ни менеджменту излишних стрессов. А стресс как известно это отношение количества задач на единицу времени. Больше задач — выше стресс, больше времени — он меньше.
И в заключение
По моим наблюдениям, лучше всего набор большого количества народа проходит в таком формате: в каждой новой команде должен быть как минимум один сотрудник, до того работавший на фирме. Идеально, если это был руководитель команды (тим лидер или ПМ) и желательно еще один рядовой сотрудник. Эти «старички» передадут корпоративную культуру новичкам, уменьшат их стресс от вхождения в новую среду и помогут решить многие бытовые проблемы. Ну и у вас получится на выходе такой же дружный коллектив, как раньше, но больше по численности.
Удачных вам расширений!
