От разработчика до руководителя

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

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

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

Кроссфункциональные команды

С кем вы хотите работать? Кому подчиняетесь? С кем сотрудничаете? Ответы очевидны и в очень маленьких компаниях (со всеми и всем), и в очень больших (до вашего прихода все уже организационно структурировано). В качестве лидера растущей компании вам придется отвечать на эти вопросы как минимум единожды, а может быть, и много раз. Каковы же будут ответы?

Я хочу уделить немного времени рассказу об одном замечательном опыте, вынесенном из работы в Rent the Runway, онлайн-сервисе аренды одежды. В ней была создана команда, совмещавшая функции разработчика ПО и подразделения по продуктам. Когда я пришла в компанию, команда инженеров-программистов была разделена примерно на две части: фасадную, занятую разработкой клиентской части сайта, и складскую, занимавшуюся поддержкой программного обеспечения, которое управляет логистикой. Мы быстро сделали так, что фасадная часть команды стала заниматься и пользовательским интерфейсом, и программно-аппаратным обеспечением, потому что переписывала код с РНР-монолита на микросервисные архитектуры, построенные на языках Java и Ruby.

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