Год назад я прочитал книгу Getting Real от 37signals. Она очень впечатлила меня, и я решил, что стоит опробовать этот подход в нашей компании, чем и занялся прямо с начала 2011 года. Эта статья — своего рода отчет о годовом опыте внедрения Getting Real в отдельно взятой компании. Отчет конечно же промежуточный, потому что о реальном эффекте от изменения подхода к работе (а Getting Real – это не методика управления или разработки, а именно подход) можно судить спустя более ощутимый промежуток времени; к тому же, не все принципы подхода мы смогли применить. Об этом я тоже расскажу.
Я не буду пересказывать содержание книги; если вы не читали ее, но интересуетесь управлением разработкой, обязательно прочитайте, она выложена в открытом доступе. Книжка совсем короткая. Если понравится — советую прочитать Rework от тех же 37signals, эта книга уже пообъёмнее.
Прежде всего надо сказать, что Getting Real наиболее эффективен в стартапах, начинающих командах. У NetCat за спиной 12 лет существования, масса кода, написанного разными людьми в разное время, сложившиеся бизнес-процессы и большая партнерская сеть. С одной стороны, это мешает: создавать заново проще, чем перестраивать. А с другой — имея за плечами большой опыт, гораздо проще сравнивать достоинства и недостатки разных подходов и методик.
Не воспринимайте эту статью как руководство по внедрению или мастер-класс: я лишь делюсь собственным опытом в формате «тезис GR — как мы его поняли и реализовали, что из этого получилось».
Каждый сотрудник компании должен приносить прибыль, прямо или косвенно. Значит, чем больше сотрудников, тем больше прибыли — при правильной организации их труда. Это правило работает далеко не всегда, особенно в IT-индустрии. Существует огромное количество примеров, когда небольшие команды энтузиастов отъедали у гигантов отрасли большие куски рынка, а то и создавали свой собственный сегмент. У больших компаний априори отсутствует мобильность, зато в избытке бюрократия, а также:
Раньше мы все время старались найти ресурсы для роста, ведь задач всегда больше, чем мы могли переварить. Наш продукт требует постоянного развития, в каждый момент существует множество задач, которые надо решать: создавать новые модули, усовершенствовать старые, выпускать отраслевые решения и так далее. Значит, нам нужно как можно больше программистов. В то же время, потенциальные партнеры нашей компании — это не только конечные пользователи сайтов, но и разработчики сайтов, хостинг-провайдеры, ритейлерские сети, розничные магазины. Значит, нужно брать больше менеджеров и маркетологов. Но что делать, если денег на расширение нет? Выходит, замкнутый круг?
С некоторых пор мы прекратили рост. Сейчас в компании работают 12 человек (на момент написания этой статьи 11, у нас вакансия программиста-стажера): программисты (4), сотрудники службы технической поддержки и сопровождения (4), менеджеры (3), проектировщик. Наши сотрудники в основном универсальны, они в той или иной степени могут выполнять работу своего соседа, если он заболеет или уйдет в отпуск. Однако всю непрофильную работу мы стараемся отдавать на аутсорс. А иногда даже и профильную. Так, два из пяти вновь созданных модулей версии NetCat 4.5, вышедшей весной 2011 года, были созданы сторонними разработчиками. За восемь месяцев 2011 года мы работали на субподряде с пятью компаниями и девятью фрилансерами. На аутсорсе мы заказываем:
Такая структура позволяет нам быть более уверенными в завтрашнем дне. У нас есть фиксированные расходы: зарплата, аренда, налоги и пр., которые меняются только при переиндексации зарплат. В то же время, продажи могут колебаться очень сильно; только в 2011 году самый худший месяц отличался по доходу от самого лучшего в два раза. Ниже приведен график наших доходов за 11 месяцев этого года, без абсолютных цифр, в процентах от максимума.
Такова специфика нашего бизнеса, когда продажи могут зависеть от очень большого количества факторов, не всегда подвластных нам. И если раньше в один месяц мы могли кататься, как сыр в масле, а в другой приходилось задерживать зарплату, то последние месяцы мы лишены этой головной боли. Лишние деньги не идут в карманы учредителей, ведь задач для аутсорса всегда хватает. Таким образом, мы с одной стороны живем по средствам, без привлечения кредитов и сторонних инвесторов, а с другой имеем возможность развиваться в гибком режиме.
Еще одно серьезное достоинство небольшого размера компании — прозрачность. Каждый человек знает, кто чем занимается, к кому подойти с какой-либо проблемой или предложением. Недовольный клиент или партнер не должен идти по цепочке уровней управления, чтобы донести свою проблему до директора. Весной этого года произошел случай, когда легкая доступность руководителя помогла нам выйти из неприятной ситуации и не потерять несколько сотен тысяч рублей.
Наконец, небольшой размер помогает сотрудникам развиваться профессионально, скрашивать необходимость год за годом выполнять одну и ту же работу. Если в штате нет, к примеру, верстальщика, который по роду деятельности был бы обязан знать Javascript и HTML5, а заказывать эту работу на сторону нецелесообразно, спихнуть её на другого не получится, приходится читать спецификации, смотреть примеры чужого кода. Это работает и по-другому. Когда однажды нам понадобилось срочно оформить раздаточный материал, оказалось, что наш дизайнер-фрилансер уехал в отпуск, и нужно срочно искать нового. Но тут выяснилось, что одна из менеджеров очень неплохо рисует. С тех пор большинство полиграфии для нас рисует она, когда это не в ущерб основной работе. Вот пара примеров:
Совещания в книге Getting Real выставляются однозначно в негативном свете. Совещания со временем превращаются в потерю рабочего времени, пережевыванию ненужной информации, разбиванию рабочего дня и т.д. Мы решили последовать совету авторов. Мы проводим общие планерки раз в неделю-две, но не используем их для выдачи заданий и заслушиванию отчетов. На таких планерках те, кому есть что рассказать, делают это — в свободной форме. Техподдержка рассказывает о своей загрузке, о необычных обращениях; руководство — о ближайших планах и проблемах, другие люди — о предстоящих мероприятиях, текущей финансовой ситуации и пр. Также на планерках обсуждается, купить ли теннисный стол в офис, поедем ли мы вместе в следующие выходное на дачу к одному из нас, что надо сменить марку кофе, потому что эта, которая в кофемашине — кислая и пр. Таким образом, все сотрудники в курсе общей ситуации в компании, не возникает вопросов «кто чем занимается» или «зачем мы это делаем». Каждый человек может высказать свое мнение по любому вопросу, даже если он не входит в его компетенцию. Хотя решения все равно принимаются теми, кто отвечает за эти решения.
Если требуется обсудить что-то конкретное, то на встречу приходят только те, кто будет на ней полезен. Когда у проектировщика возникает вопрос к разработчикам на тему сложности реализации какого-то интересного функционала, он зовет ведущего разработчика «прямо сейчас»; если для решения вопроса требуется участие большого количества сотрудников, назначаем время «через час» или «завтра».
Также мы отказались от фиксированного рабочего дня для основной части сотрудников. У нас только три человека обязаны быть в офисе с десяти часов: дежурный сотрудник техподдержки, менеджер-администратор и менеджер по работе с партнерами. Это те роли, которые действительно нужны в течение общепринятого рабочего дня. Все остальные работают в том режиме, которым им удобен. Мы опасались, что это приведет к появлению «халявщиков», которые ничего не делают, а только получают зарплату. Такие действительно были, но распознать их очень легко. Впрочем, для них и присутствие на рабочем месте не означает эффективной работы. Зато остальные чувствуют себя гораздо более комфортно, и это очень сильно влияет на эффективность работы. Если человек любит поспать подольше и лечь попозже, зачем его ломать? Если какой-то важный кусок программы сотрудник хочет написать дома, где ему не мешают коллеги, зачем заставлять его сидеть в офисе?
Последние года полтора мы берем на работу исключительно на позицию стажера (это не догма, просто так сложилось). Все программисты, работающие сейчас в компании, приходили в нее именно стажерами, начинавшими со службы поддержки, тестирования, помощи разработчикам в элементарных задачах. Для нас такая стратегия однозначно выигрышна. Мы не сталкиваемся с чужими привычками и подходами к разработке ПО, противоречащими нашим. Мы всегда имеем резерв, который может быть быстро задействован, если разработчик решает уйти из компании.
Конечно, такой подход является спорным. Его недостаток в следующем. Беря на работу неопытного сотрудника, мы фактически покупаем кота в мешке, ведь мы можем ошибиться в оценке его потенциала. В этом случае через несколько недель или месяцев человек уходит из компании, а ведь мы вложили в него время и деньги. С этим приходится мириться. Иногда возникает обратная ситуация: сотрудник растет быстрее компании, ему уже не интересно сидеть на технической поддержке, а мы прямо сейчас не можем предложить ему рост. Такие ситуации еще более обидны, но создавать рабочие места под хороших людей — порочная практика.
Мы все хотим видеться другим людям более умными и успешными, чем мы есть на самом деле. Отчасти это оправдано: никто не любит неудачников. Но когда ты слышишь о сплошной истории успеха, но не видишь подтверждений этому, ты перестаешь верить собеседнику даже в том, в чем он не врет.
Не то, чтобы мы совсем ничего не скрываем… ;) Но мы стараемся. Например, мы перестали замалчивать факты взлома нашего продукта, даже наоборот: по регламенту в случае обнаружения критической уязвимости мы выпускаем экстренный патч, открываем доступ к нему всем (а не только тем, у кого активна техническая поддержка) и рассылаем пользователям и партнерам уведомления. Также мы перестали скрывать от сотрудников наши финансовые показатели и детали планов по завоеванию мира. Мы стараемся честно отвечать на вопросы, почему у нас нет того или иного функционала и планируем ли мы его вводить. И пока мы не сталкивались с тем, чего боялись: оттока разочарованных партнеров нет, сотрудники не бегут продавать наши секреты конкурентам (да и особых секретов на продажу, как оказалось, у нас и нет; по крайней мере, мы сами не понимаем, как бы воспользовались аналогичным знанием из стана конкурентов).
Наоборот, мы увидели, что люди ценят нашу честность, стараются помогать, лучше понимают нас. Это снимает проблему разочарований из-за завышенных ожиданий.
Эта мысль проходит в книге красной нитью. Продукты нужно разрабатывать не для абстрактных пользователей, а для себя, чтобы вам самим было удобно ими пользоваться. Например, модуль «Минимагазин» (только функция помещения в корзину, управление ей, отправка заказа на email и архив заказов; никакого 1С-а, онлайн-оплаты, сравнения товаров и пр.; но подключается он к каталогу товаров за считанные минуты) я придумал год назад для сайта моей мамы, после чего мы решили выпустить его в продуктовой линейке. Сейчас по статистике продаж он занимает второе место после «Личного кабинета».
Проекты нельзя делать под продажу, наоборот, у вас должно быть четкое понимание, как проект будет жить сам по себе. Команду надо строить не так, как у известных компаний, а так, как удобно вам, с учетом ваших пробелов в знаниях и управленческих недостатков. Нельзя позволять клиентам навязывать вам видение продукта, иначе вы всегда будете ведомой компанией и никакие инновации вашему продукту не светят. Более успешных конкурентов копировать нельзя, иначе вы всегда останетесь компанией номер два или пять или двадцать пять. Несколько лет назад я видел в Интернете смешной демотиватор типа такого:
Мир глазами первой лошади в упряжке
Мир глазами второй лошади в упряжке
Мы всегда будем видеть перед собой только чью-то задницу, если не будем самими собой.
В следующей части статьи: «ограничения помогают», «не создавайте спецификации»; а также что из принципов GR у нас не получилось.
Я не буду пересказывать содержание книги; если вы не читали ее, но интересуетесь управлением разработкой, обязательно прочитайте, она выложена в открытом доступе. Книжка совсем короткая. Если понравится — советую прочитать Rework от тех же 37signals, эта книга уже пообъёмнее.
Прежде всего надо сказать, что Getting Real наиболее эффективен в стартапах, начинающих командах. У NetCat за спиной 12 лет существования, масса кода, написанного разными людьми в разное время, сложившиеся бизнес-процессы и большая партнерская сеть. С одной стороны, это мешает: создавать заново проще, чем перестраивать. А с другой — имея за плечами большой опыт, гораздо проще сравнивать достоинства и недостатки разных подходов и методик.
Не воспринимайте эту статью как руководство по внедрению или мастер-класс: я лишь делюсь собственным опытом в формате «тезис GR — как мы его поняли и реализовали, что из этого получилось».
Оставайтесь маленькими
Каждый сотрудник компании должен приносить прибыль, прямо или косвенно. Значит, чем больше сотрудников, тем больше прибыли — при правильной организации их труда. Это правило работает далеко не всегда, особенно в IT-индустрии. Существует огромное количество примеров, когда небольшие команды энтузиастов отъедали у гигантов отрасли большие куски рынка, а то и создавали свой собственный сегмент. У больших компаний априори отсутствует мобильность, зато в избытке бюрократия, а также:
- Совещания
- Документооборот
- Фиксированные зарплатные ставки
- Уровни доступа
- Управленческие цепочки
- Стратегическое планирование
- Детальное проектирование
- Штатное расписание
- Система поощрений и наказаний
Раньше мы все время старались найти ресурсы для роста, ведь задач всегда больше, чем мы могли переварить. Наш продукт требует постоянного развития, в каждый момент существует множество задач, которые надо решать: создавать новые модули, усовершенствовать старые, выпускать отраслевые решения и так далее. Значит, нам нужно как можно больше программистов. В то же время, потенциальные партнеры нашей компании — это не только конечные пользователи сайтов, но и разработчики сайтов, хостинг-провайдеры, ритейлерские сети, розничные магазины. Значит, нужно брать больше менеджеров и маркетологов. Но что делать, если денег на расширение нет? Выходит, замкнутый круг?
С некоторых пор мы прекратили рост. Сейчас в компании работают 12 человек (на момент написания этой статьи 11, у нас вакансия программиста-стажера): программисты (4), сотрудники службы технической поддержки и сопровождения (4), менеджеры (3), проектировщик. Наши сотрудники в основном универсальны, они в той или иной степени могут выполнять работу своего соседа, если он заболеет или уйдет в отпуск. Однако всю непрофильную работу мы стараемся отдавать на аутсорс. А иногда даже и профильную. Так, два из пяти вновь созданных модулей версии NetCat 4.5, вышедшей весной 2011 года, были созданы сторонними разработчиками. За восемь месяцев 2011 года мы работали на субподряде с пятью компаниями и девятью фрилансерами. На аутсорсе мы заказываем:
- бухгалтерские и юридические услуги
- дизайнерские работы
- верстку
- разработку (частично)
- рекламные услуги, организацию событий
- тестирование (частично)
- аудит (юзабилити, безопасность)
- администрирование наших серверов
- уборку :)
Такая структура позволяет нам быть более уверенными в завтрашнем дне. У нас есть фиксированные расходы: зарплата, аренда, налоги и пр., которые меняются только при переиндексации зарплат. В то же время, продажи могут колебаться очень сильно; только в 2011 году самый худший месяц отличался по доходу от самого лучшего в два раза. Ниже приведен график наших доходов за 11 месяцев этого года, без абсолютных цифр, в процентах от максимума.
Такова специфика нашего бизнеса, когда продажи могут зависеть от очень большого количества факторов, не всегда подвластных нам. И если раньше в один месяц мы могли кататься, как сыр в масле, а в другой приходилось задерживать зарплату, то последние месяцы мы лишены этой головной боли. Лишние деньги не идут в карманы учредителей, ведь задач для аутсорса всегда хватает. Таким образом, мы с одной стороны живем по средствам, без привлечения кредитов и сторонних инвесторов, а с другой имеем возможность развиваться в гибком режиме.
Еще одно серьезное достоинство небольшого размера компании — прозрачность. Каждый человек знает, кто чем занимается, к кому подойти с какой-либо проблемой или предложением. Недовольный клиент или партнер не должен идти по цепочке уровней управления, чтобы донести свою проблему до директора. Весной этого года произошел случай, когда легкая доступность руководителя помогла нам выйти из неприятной ситуации и не потерять несколько сотен тысяч рублей.
Наконец, небольшой размер помогает сотрудникам развиваться профессионально, скрашивать необходимость год за годом выполнять одну и ту же работу. Если в штате нет, к примеру, верстальщика, который по роду деятельности был бы обязан знать Javascript и HTML5, а заказывать эту работу на сторону нецелесообразно, спихнуть её на другого не получится, приходится читать спецификации, смотреть примеры чужого кода. Это работает и по-другому. Когда однажды нам понадобилось срочно оформить раздаточный материал, оказалось, что наш дизайнер-фрилансер уехал в отпуск, и нужно срочно искать нового. Но тут выяснилось, что одна из менеджеров очень неплохо рисует. С тех пор большинство полиграфии для нас рисует она, когда это не в ущерб основной работе. Вот пара примеров:
Меньше совещаний, больше свободы
Совещания в книге Getting Real выставляются однозначно в негативном свете. Совещания со временем превращаются в потерю рабочего времени, пережевыванию ненужной информации, разбиванию рабочего дня и т.д. Мы решили последовать совету авторов. Мы проводим общие планерки раз в неделю-две, но не используем их для выдачи заданий и заслушиванию отчетов. На таких планерках те, кому есть что рассказать, делают это — в свободной форме. Техподдержка рассказывает о своей загрузке, о необычных обращениях; руководство — о ближайших планах и проблемах, другие люди — о предстоящих мероприятиях, текущей финансовой ситуации и пр. Также на планерках обсуждается, купить ли теннисный стол в офис, поедем ли мы вместе в следующие выходное на дачу к одному из нас, что надо сменить марку кофе, потому что эта, которая в кофемашине — кислая и пр. Таким образом, все сотрудники в курсе общей ситуации в компании, не возникает вопросов «кто чем занимается» или «зачем мы это делаем». Каждый человек может высказать свое мнение по любому вопросу, даже если он не входит в его компетенцию. Хотя решения все равно принимаются теми, кто отвечает за эти решения.
Если требуется обсудить что-то конкретное, то на встречу приходят только те, кто будет на ней полезен. Когда у проектировщика возникает вопрос к разработчикам на тему сложности реализации какого-то интересного функционала, он зовет ведущего разработчика «прямо сейчас»; если для решения вопроса требуется участие большого количества сотрудников, назначаем время «через час» или «завтра».
Также мы отказались от фиксированного рабочего дня для основной части сотрудников. У нас только три человека обязаны быть в офисе с десяти часов: дежурный сотрудник техподдержки, менеджер-администратор и менеджер по работе с партнерами. Это те роли, которые действительно нужны в течение общепринятого рабочего дня. Все остальные работают в том режиме, которым им удобен. Мы опасались, что это приведет к появлению «халявщиков», которые ничего не делают, а только получают зарплату. Такие действительно были, но распознать их очень легко. Впрочем, для них и присутствие на рабочем месте не означает эффективной работы. Зато остальные чувствуют себя гораздо более комфортно, и это очень сильно влияет на эффективность работы. Если человек любит поспать подольше и лечь попозже, зачем его ломать? Если какой-то важный кусок программы сотрудник хочет написать дома, где ему не мешают коллеги, зачем заставлять его сидеть в офисе?
Нанимайте меньше и реже
Последние года полтора мы берем на работу исключительно на позицию стажера (это не догма, просто так сложилось). Все программисты, работающие сейчас в компании, приходили в нее именно стажерами, начинавшими со службы поддержки, тестирования, помощи разработчикам в элементарных задачах. Для нас такая стратегия однозначно выигрышна. Мы не сталкиваемся с чужими привычками и подходами к разработке ПО, противоречащими нашим. Мы всегда имеем резерв, который может быть быстро задействован, если разработчик решает уйти из компании.
Конечно, такой подход является спорным. Его недостаток в следующем. Беря на работу неопытного сотрудника, мы фактически покупаем кота в мешке, ведь мы можем ошибиться в оценке его потенциала. В этом случае через несколько недель или месяцев человек уходит из компании, а ведь мы вложили в него время и деньги. С этим приходится мириться. Иногда возникает обратная ситуация: сотрудник растет быстрее компании, ему уже не интересно сидеть на технической поддержке, а мы прямо сейчас не можем предложить ему рост. Такие ситуации еще более обидны, но создавать рабочие места под хороших людей — порочная практика.
Будьте открытыми
Мы все хотим видеться другим людям более умными и успешными, чем мы есть на самом деле. Отчасти это оправдано: никто не любит неудачников. Но когда ты слышишь о сплошной истории успеха, но не видишь подтверждений этому, ты перестаешь верить собеседнику даже в том, в чем он не врет.
Не то, чтобы мы совсем ничего не скрываем… ;) Но мы стараемся. Например, мы перестали замалчивать факты взлома нашего продукта, даже наоборот: по регламенту в случае обнаружения критической уязвимости мы выпускаем экстренный патч, открываем доступ к нему всем (а не только тем, у кого активна техническая поддержка) и рассылаем пользователям и партнерам уведомления. Также мы перестали скрывать от сотрудников наши финансовые показатели и детали планов по завоеванию мира. Мы стараемся честно отвечать на вопросы, почему у нас нет того или иного функционала и планируем ли мы его вводить. И пока мы не сталкивались с тем, чего боялись: оттока разочарованных партнеров нет, сотрудники не бегут продавать наши секреты конкурентам (да и особых секретов на продажу, как оказалось, у нас и нет; по крайней мере, мы сами не понимаем, как бы воспользовались аналогичным знанием из стана конкурентов).
Наоборот, мы увидели, что люди ценят нашу честность, стараются помогать, лучше понимают нас. Это снимает проблему разочарований из-за завышенных ожиданий.
Будьте собой
Эта мысль проходит в книге красной нитью. Продукты нужно разрабатывать не для абстрактных пользователей, а для себя, чтобы вам самим было удобно ими пользоваться. Например, модуль «Минимагазин» (только функция помещения в корзину, управление ей, отправка заказа на email и архив заказов; никакого 1С-а, онлайн-оплаты, сравнения товаров и пр.; но подключается он к каталогу товаров за считанные минуты) я придумал год назад для сайта моей мамы, после чего мы решили выпустить его в продуктовой линейке. Сейчас по статистике продаж он занимает второе место после «Личного кабинета».
Проекты нельзя делать под продажу, наоборот, у вас должно быть четкое понимание, как проект будет жить сам по себе. Команду надо строить не так, как у известных компаний, а так, как удобно вам, с учетом ваших пробелов в знаниях и управленческих недостатков. Нельзя позволять клиентам навязывать вам видение продукта, иначе вы всегда будете ведомой компанией и никакие инновации вашему продукту не светят. Более успешных конкурентов копировать нельзя, иначе вы всегда останетесь компанией номер два или пять или двадцать пять. Несколько лет назад я видел в Интернете смешной демотиватор типа такого:
Мир глазами первой лошади в упряжке
Мир глазами второй лошади в упряжке
Мы всегда будем видеть перед собой только чью-то задницу, если не будем самими собой.
В следующей части статьи: «ограничения помогают», «не создавайте спецификации»; а также что из принципов GR у нас не получилось.
