Добрый день. Меня зовут Ранис Усманов, я руководитель компании «Крон». Свою компанию я создал за полтора года, и сейчас в ней трудится 38 высококвалифицированных разработчиков. Плюс я запустил сервис по онлайн-собеседованию программистов 1С.
О себе
В сфере 1С я более десяти лет. Проработал в различных аутсорсинговых компаниях – в последней из них я работал руководителем проектов. Там я создал самую прибыльную команду в отделе сопровождения 1С. Также занимался разработкой и попутно подбором и обучением персонала.
Я являюсь сертифицируемым преподавателям 1С и автором сертифицированных курсов.
Сегодня я хотел бы поделиться своими навыками и опытом по созданию аутсорсинговой компании удаленных программистов 1С.
О чем доклад
Секцию «Управление персоналом» на конференции я выбрал не просто так. Я считаю, что кадры решают все.
И сегодня мы рассмотрим следующие моменты:
- как собрать команду: как привлечь сильных разработчиков к себе;
- как организовать эффективную работу разработчиков и настроить их на максимальную клиентоориентированность;
- как добиться хорошего учета и контроля времени;
- как добиться закрытия часов – не менее 150 в месяц по каждому сотруднику;
- как организовать работу сотрудников в разных часовых поясах;
- какие бывают системы мотивации, кроме заработной платы;
- как эффективно решать проблемы, возникающие при работе;
- и рассмотрим некоторые категории сотрудников – такие как «герой», «интроверт» и «пассажир».
Как собрать команду
Первый вопрос – как собрать команду и привлечь сотрудников.
Ни для кого не секрет, что сегодня спрос на сильных разработчиков один из самых высоких, и одной хорошей заработной платы не хватает. Чтобы привлечь разработчиков необходимо использовать какие-то дополнительные инструменты.
Чтобы понять, какие инструменты использовать, надо посмотреть глазами самого разработчика. Когда он начинает анализировать рынок, то видит множество компаний, которые предлагают высокую заработную плату. Поскольку разницы между зарплатами практически нет, разработчик начинает оперировать различными критериями, например, такими как:
- финансовая стабильность;
- возможность заниматься только разработкой;
- нормированный график;
- профессиональный и карьерный рост;
- команда компании.
Эти топ-5 критериев я выбрал не просто так. За последние три года я прособеседовал более 2000 кандидатов – это дало мне возможность собрать информацию, что мотивировало их принять предложение от работодателя, а что демотивировало, какие были причины сменить работу.
- Почти 100% разработчиков сейчас хотят видеть финансовую стабильность в лице самого работодателя. Они хотят получать всегда вовремя ту зарплату, о которой они договаривались с работодателем при приёме на работу. Зарплата не должна зависеть от оплаты клиентов, от выработки, от простоев и каких-то необоснованных штрафов. Нам придется с этим мириться, потому что сейчас очень много компаний, которые предлагают примерно те же самые оклады, выплачивая их вовремя и стабильно. Поэтому мы обязательно должны предоставить разработчику некую финансовую стабильность.
- Следующий пункт – заниматься только разработкой. Работа с конечными пользователями – один из наиболее сильных демотиваторов для разработчиков. Речь идет про обучение, консультирование и получение задач от сотрудников компании-клиента – бухгалтеров, экономистов, финансистов и т.д. Этой работой все-таки должны заниматься именно консультанты или аналитики – именно они должны ставить задачу перед разработчиком. Ни в коем случае не подключайте к этому конечных пользователей. Разработчики должны заниматься разработкой и получать задачи только от консультантов и аналитиков. Но, конечно, если вы хотите, чтобы разработчик быстро ушел по собственному желанию, то можно его отправить на обучение пользователей.
- Нормированный график. Надо понимать, что сильные разработчики – это люди, которые знают цену своему времени и самим себе. Плюс это люди от 25 лет, у которых уже есть семья, некие увлечения и обязательства, на которые тоже надо уделять время. Причем нормированный график – это удобно для разработчика, а также выгодно для работодателя. Потому что при нормированном графике вы можете получить максимальную эффективность от работы сотрудника. Если вы не предоставляете ему нормированный график, то его эффективность будет похожа на американские горки, что очень бьет по прибыли.
- Если говорить про профессиональный и карьерный рост, то 60-70% разработчиков поставили профессиональный рост выше карьерного роста. Потому что сильные специалисты очень много времени и сил потратили на то, чтобы получить свою квалификацию, и для них, как минимум, очень важно ее поддерживать. А лучше – повышать. У меня есть разработчики, которые ко мне пришли только из-за того, что на предыдущей работе у них не было возможности поддерживать свою квалификацию. И это огромный риск – они боятся, что со временем станут неконкурентоспособными на рынке. Я уже не говорю про то, что им неинтересно делать какие-то мелкие задачи. Так что нам всегда нужно уделять время на то, чтобы предоставлять возможность разработчикам как минимум поддерживать свою квалификацию, а лучше – повышать ее. Мы, к примеру, собираем карту знаний разработчиков, получаем информацию, где у них есть какие-то пробелы, стараемся их подтягивать. В целом мои разработчики как раз за счет этого и хотят дальше работать в нашей компании.
- 30-40% рассказали о желании карьерного роста – стать, к примеру, руководителями проектов, архитекторами и т.д. Конечно, не все могут предоставить возможность карьерного роста, но надо попытаться это давать.
- Последний критерий – команда компании. Здесь подразумевается следующее: половина наших кандидатов хотят работать в сильной команде. Сильная команда – один из хороших источников для повышения квалификации. Это некий подпункт к профессиональному росту.
Не все работодатели, конечно, могут предоставить все возможности – в некоторых компаниях нет ресурсов на то, чтобы повышать профессиональный и карьерный рост, у кого-то нет сильной команды, могут быть слабые разработчики. Этот набор критериев – некий микс, но в целом надо стараться давать хотя бы первые три пункта: финансовую стабильность, возможность заниматься только разработкой и нормированный график.
Как организовать эффективную работу
Чтобы организовать эффективную работу и настроить разработчиков на максимальную клиентоориентированность, необходимо доносить информацию людям о важности их работы и о правилах компании. Это делается не один раз – мы периодически об этом говорим, рассуждаем.
Когда мы доносим информацию о максимальной эффективности разработчиков, о максимальной клиентоориентированности, о важности правил компании, необходимо помнить одно – не надо предоставлять эту информацию в ключе выгоды компании. Поймите, что для сотрудника ваша компания – это ваша проблема. Когда вы доносите информацию в ключе выгоды компании, это не очень хорошо доходит. Поэтому не надо оперировать такими понятиями, как:
- мы потеряем клиента;
- мы понесем убытки;
- мы получим негативный отзыв от клиента.
Лучше эту информацию доносить в ключе выгоды самого сотрудника.
- Например, почему важен лояльный клиент. Мы объясняем, в чем выгода разработчику от лояльного клиента. Если клиент будет максимально лоялен к сотруднику, то сотруднику будет проще и легче работать, получать от него задачи и решать какие-то проблемы. Плюс мы все люди, все допускаем ошибки, и если клиент будет лоялен к сотруднику, то, в принципе, он может на что-то закрыть глаза. Если лояльности не будет, то разработчик может получить «пучок негатива» от клиента, и тем самым ему будет неудобно работать.
- Следующий момент – финансовая выгода. Мы доносим информацию о том, что если клиент лояльный, то мы можем получить положительный отзыв или рекомендацию. Тот же самый клиент может нарастить объемы, что увеличит выручку и нашу финансовую стабильность. А если увеличивается выручка, у нас появляется возможность, как минимум, за положительный отзыв дать сотруднику премию одноразово или вообще повысить ему заработную плату. То есть благодаря лояльному клиенту разработчик получает некую финансовую выгоду.
- Третий пункт – возможность профессионального и карьерного роста. Если у нас увеличатся финансовая стабильность и выручка, то мы сможем запускать новые проекты, новые сервисы и новые направления. Тем самым у нас увеличится штат, и мы сможем предоставить возможность разработчикам стать руководителями проектов, архитекторами и т.д.
Если доносить информацию в таком ключе, то вы получите максимальную эффективность. Разработчик будет сам заинтересован работать максимально эффективно и по правилам компании.
Учет и контроль времени
У многих, наверное, есть такая проблема: сотрудники не всегда или не вовремя заносят данные об отработанных часах или заносят часы неправильно.
Я пробовал различные методики, читал разные книжки, использовал всевозможные системы. Но все свелось к минимуму:
- Мне самому, как работодателю, выгодно, чтобы сотрудники заносили часы вовремя, правильно и ежедневно. К примеру, появилась задача, ее заносят в систему, по каждому заданию делаются записи о работе – что сделали и сколько времени на это потратили. Я не прошу своих разработчиков писать «Войну и мир» в трех томах и описывать вплоть до строчки, что они поменяли. Это бессмысленно и невыгодно.
- Моя логика простая – запись должна сама себя продавать. Клиент должен понимать, за что он платит, и на что у него время уходит. Если разработчик может уложить описание работы в одном предложении из трех слов, клиент доволен и понимает, за что он платит, меня это устраивает.
Чтобы разработчики заносили вовремя часы, мы используем несколько правил.
- Моя помощница в 8 часов утра в общий чат пишет примерно следующее: «Доброе утро, занесите, пожалуйста, часы за вчерашний день. Спасибо!». 80% сотрудников, которые до этого времени не занесли часы, уже это делают.
- В 10 утра по мск идет электронное оповещение о необходимости занесения часов за вчерашний день. Это предупреждение о том, что после 12 часов редактировать ничего нельзя. На этом этапе все, кто не успел, тоже заносят свои часы, и у нас сейчас проблем нет.
- Раньше нам приходилось использовать еще третье правило: обращаться к руководителю, когда период редактирования закрыт. Разработчики обращаются ко мне, чтобы внести изменения или занести часы.
Но перед тем как открыть период, я им всегда доносил информацию о том, что им самим выгодно занести информацию вовремя:
- Опять же приводил в пример лояльного клиента, говорил об их выгоде в ключе лояльного клиента, показывал, где именно мы можем получить лояльность. Ведь когда клиент всегда может оперативно получить информацию о своих затратах – что конкретно было сделано, сколько на это времени было потрачено, мы все получаем некую лояльность – и компания, и сам сотрудник.
- Отсюда идет еще одна его выгода от лояльного клиента – довольный руководитель. Иными словами, если человек всегда заносит часы вовремя, всегда правильно, клиент доволен, у меня нет проблем по выставлению счетов, мы получаем положительные отзывы, и все это идёт человеку в копилку, и как минимум, это очень хороший повод его премировать, а может, и повысить ему заработную плату.
- Кроме того, это экономия времени. Дело в том, что когда я доношу всю эту информацию сотруднику, я доношу ее от получаса до нескольких часов. Мы с разработчиком сидим, рассуждаем о выгоде, какие могут возникнуть моменты и так далее. И получается, что если бы он ежедневно правильно и вовремя заносил часы, то он тратил бы максимум 5 минут в день. А в противном случае он будет со мной общаться полчаса-час, бывало, и до 3 часов доходило. Правда, после такого общения человек больше никогда не захочет дойти до 3 пункта, и сейчас у нас все заносят часы корректно и вовремя – до 12 часов по мск.
Так что здесь в принципе никаких проблем нет – есть простые правила, которые нам помогают.
О закрытии не менее 150 часов в месяц
Следующий момент – это закрытие часов не менее 150 часов в месяц.
- Когда мы запускались, мы использовали такое правило: если разработчик видит, что у него задача заканчивается через полчаса, час, день, то он обязательно должен предупредить об этом клиента и руководителя. Если человек уже по факту скажет, что у него задачи закончились, мы не всегда сможем оперативно дать ему работу. Действительно, у нас есть пул задач, но не всегда можно все бросить и уделить время на пояснения по постановке. Я доношу следующую информацию: я плачу за каждый час вне зависимости от простоев и выработки и хочу, чтобы каждый час было максимально эффективным. Здесь должно быть некое взаимоуважение. Поэтому разработчику необходимо предупреждать клиента и руководителя заранее, чтобы мы подготовили и предоставили ему пул задач. Это помогало, но все равно было около 20-30 часов простоя на сотрудника в месяц.
- Меня это не очень устроило, и мы сделали следующее. В нашей системе мы создали панельку с мелкими задачами, которые были не срочные, их и через неделю можно было решить. К каждой задаче имеется маленькое описание и предварительная оценка по времени выполнения. И когда разработчик уходил в простой, и мы не могли ему оперативно дать задачу, он благодаря предварительной оценке мог выбрать подходящие по времени выполнения задачи. Это нам помогло сократить количество простоев до 5-6 часов на сотрудника в месяц.
- На сегодняшний день у нас все разработчики загружены на full-time, работают по 8 часов в день 5 дней в неделю, от месяца и более на клиента. Это нам сократило количество простоев до 0. Здесь я немного согрешил: за последние два месяца – июль и август – мы получили грандиозное количество простоев: 12 часов на 38 разработчиков. Но мы пытаемся добиться, чтобы клиенты хотели работать с нами на full-time благодаря заинтересованности сотрудников, максимальной эффективности и клиентоориентированности. Сейчас у нас проблем с простоями нет.
Организация работы сотрудников в разных часовых поясах
Следующий момент – организация работы сотрудников в разных часовых поясах. Здесь ничего сложного нет, эту проблему можно решить двумя способами.
- Первый. Клиент находится в том же часовом поясе, что и разработчик. Сейчас в России очень много ведется внедрения и сопровождения 1С, и по всем областям идет дикая нехватка сильных разработчиков. И вы можете найти и клиента, и сотрудника, которые находятся в одном часовом поясе. И тогда всем будет хорошо.
- Если у вас нет такой возможности, например, у меня разработчики находятся от Барнаула до Калининграда, то есть второй способ – сделать сдвиг рабочего времени +/- 4 часа. У меня есть клиент, который работает в Москве с 9 до 18, а мои разработчики, к примеру, начинают работать в 4 или 5 утра. Здесь самое главное, чтобы разработчик вовремя получал пул задач с неким описанием и пояснениями по ним. Мне кто-то говорил, что такой вариант работы подходит для малого и среднего бизнеса, а крупные компании и госкомпании никогда ни в коем случае не согласятся так работать – они диктуют свои правила. Но на самом деле это не так. У нас сейчас большой пул крупных клиентов – крупные российские компании, крупные международные компании, и мы с ними работаем в режиме +/- 4 часа сдвиг. Все довольны, и никаких проблем нет.
Система мотивации, кроме заработной платы
Какие есть способы мотивации:
- Самое простое – это найти повод, чтобы поблагодарить сотрудника. Например, если вы получили положительный отзыв, или сотрудник повысил квалификацию, обязательно поблагодарите его. Поблагодарите перед всеми. Вы же понимаете, что сильные разработчики – это творческие люди, а любая творческая душа требует признания. Достаточно просто поблагодарить перед всеми, сказать, что благодаря работе Васи Пупкина нам прислали положительный отзыв, спасибо ему. Это дает некий стимул разработчику и дальше быть максимально эффективным и клиенториентированным.
- Работа в команде – еще один способ мотивации. Она очень хорошо помогает повышению квалификации. Раньше мы каждому разработчику индивидуально закупали какие-то курсы, или я сам их проводил. Но особого эффекта не было – курсы откладывались в долгий ящик. Потом получилось так, что один из наших разработчиков создал чат под названием «Философский чат по программированию», и все втянулись в это дело. Там частенько обсуждают разные моменты по оптимизации, по производительности, по новым механизмам, методикам и стандартам 1С. Обсуждают, как лучше сделать, как будет более оптимально и правильно. Я к этому время как раз прекратил закупать всякие курсы, прекратил что-то преподавать и решил посмотреть, насколько такое общение будет эффективно. Через 3 месяца, когда мы проверили знания, я увидел, что у разработчиков в среднем на 5-10% повысилась квалификация. У некоторых сотрудников были проблемы с обменами, с оптимизацией, и они подтянулись в этих темах благодаря работе этого чата. Причем, они никак не включались, другие ребята сами обсуждали, как будет оптимально и правильно.
- Следующий момент: обязательно информируйте сотрудников, какие цели мы ставим перед собой, куда мы движемся, чего мы хотим достигнуть, как мы планируем этого достигнуть, и что нам для этого нужно сделать. Для каждого человека всегда нужны какие-то новые цели. Поэтому информируем людей о планах и целях компании. В дальнейшем, когда мы достигаем этих целей, обязательно необходимо сообщать сотрудникам, что мы достигли цели, объяснять, благодаря чему мы их достигли, что мы от этого получили, и в чем выгода для самих сотрудников. Если сотрудники видят ваши достижения, видят цели компании, они верят в вашу компанию и с энтузиазмом работают. Если вы не будете выдавать информацию, чего вы достигли, какие у вас показатели и так далее, то обычно сотрудники начинают теряться, они начинают считать, что компания никуда не движется, у них начинают возникать какие-то негативные эмоции.
- Поэтому всегда необходимо информировать людей о достижениях и планах компании. И мы обязательно доносим информацию, как мы это сделаем, что мы получим, и в чем выгода именно сотрудников. Никогда нельзя забывать рассказать, в чем будет выгода самого сотрудника.
Эффективное решение проблем, возникающих при работе
Здесь всего два пункта:
- оперативность;
- руководить всегда открыт и готов помочь.
В ходе работы возникают различные проблемы – они могут возникнуть или в технической части, или при коммуникации с клиентом (какой-то негатив или недопонимание). И очень часто надо доносить информацию, что любую проблему надо решать оперативно.
- К примеру, проблема с технической частью. Человек 10-15 минут не может решить какую-то задачу, бывает такое. Лучше сообщить об этом в чат, коллеги обязательно помогут. Даже можно обратиться к руководителю, и если будет возможность, я обязательно подключусь и помогу. Тут опять доносится информация, что если он пытается сам решить эту задачу, то может потратить на это день-два. Из-за этого мы получаем некий негатив от клиента, теряем его лояльность, а разработчик теряет некую свою выгоду. Поэтому лучше решать эти проблемы оперативно.
- Если, к примеру, возникает какой-то негатив в коммуникации с клиентом или какое-то недопонимание, тоже обращайся, пожалуйста, к руководителю. Мы подскажем, как себя вести по своему опыту, сам руководитель может подключиться, чтобы проблему решить. Если это затягивать, то, скорее всего, будет опять какой-то негатив со стороны клиента, причем обоснованный, и самому разработчику будет тяжело работать.
У нас сейчас ребята все максимально оперативно сообщают о возникающих проблемах. Единственная сложность по поводу оперативности возникает у новых сотрудников. Но эта проблема быстро решается, главное – всегда доносить информацию, зачем это нужно, где будет выгода разработчика.
Категории сотрудников: герой, интроверт и пассажир
Я выбрал эти категории, хотя есть, конечно, много других. Но мне эти наиболее интересны.
Герой
Это моя самая любимая категория сотрудников. У героя есть множество положительных сторон, но есть и свои минусы. Положительная сторона: за счет своего героизма человек в принципе может вытянуть весь ваш проект. Если горят сроки, проект тонет, то именно эти сотрудники благодаря своим ресурсам вытянут проект. Они могут перерабатывать по 14-16 часов, работать 7 дней в неделю несколько месяцев подряд. Это не очень хорошо, но за счет этого героизма они частенько вытягивают проекты. Клиенты остаются довольными, мы получаем положительные отзывы.
Но есть и минусы, и на них надо акцентировать свое внимание. Первый минус в том, что если вы подключаете такого героя к клиенту, клиент, ясное дело, доволен, какой разработчик молодец, вытянул проект. Но когда вы подключаете второго сотрудника, не героя, который тоже сильный разработчик, но работает стандартно, не геройствует (не работает по 10-12 часов), то клиенту будет казаться, что второй разработчик более слабый по сравнению с первым. Тут приходится доказывать и объяснять клиенту, что проблема не во втором, а по большей части в первом. Потому что герои – это исключение, и таких ребят маловато.
Второй момент: за счет своего героизма они очень хорошо вытягивают проекты, но они потом выдыхаются, их эффективность очень сильно падает. У меня есть разработчик, который тоже однажды проявил героизм, вытянул проект, клиент доволен, все замечательно. Но через пару месяцев у него эффективность очень сильно упала, он делал задачу две недели, которую в принципе мог сделать за 2 часа. Сам клиент подтверждал, что он эти же задачи решал за два часа, а сейчас – за две недели. Тут, конечно, сработало то, что клиент понимал, благодаря чему эффективность упала, и в принципе закрыл на это глаза.
Героев очень тяжело контролировать, чтобы они не перерабатывали. Частенько вы даже не будете знать, что человек перерабатывает. Он просто будет работать ради компании, ради проекта, ради клиента. Не будет это афишировать.
Интроверт
Бытует мнение, что интроверты не общительны. Это так. У меня есть несколько разработчиков интровертов, и в первое время у меня с ними не получалось пообщаться более 5 минут. Через 5 минут, а то и раньше, они мне очень хорошо давали понять, что они со мной общаться не хотят, им не интересно. Но если вопрос возникает по поводу того, подключать их клиенту или нет, то не переживайте, будет все хорошо.
Надо понимать, что интроверты – это не изгои, а люди, которые сконцентрированы на своей работе и общении с клиентом. Получение от него задач, уточнение этих задач и их выполнение является частью их работы. Они сконцентрированы полностью на своей работе и выполняют ее всегда вовремя. Ни один мой разработчик-интроверт ни разу не сорвал сроки, и клиенты всеми ими довольны. Я хотел бы больше таких интровертов к себе в команду, потому что с ними всегда можно строить планы. Если интроверт сказал, что выполнит задачу через 3 часа, он это сделает.
Пассажир
Самая не любимая моя категория, но, тем не менее, с ними работать можно. Просто надо понимать следующее: если вы наняли сотрудника-пассажира с определенной квалификацией, с этой квалификацией он и будет работать. Их никак нельзя мотивировать на клиентоориентированность, на максимальную эффективность, на повышение квалификации и т.д. Они уже достигли своей цели, когда к вам пришли на работу, они получили ту зарплату, которую они хотели. Больше их ничего не интересует. Исключением по повышению квалификации может быть только то, что они получили некое задание, где есть механизм, который они до этого не изучали. В этом случае человек изучит механизм, но изучит ровно настолько, чтобы выполнить поставленную задачу.
Если таких пассажиров 1-2, это неплохо, можно их держать. Но ни в коем случае не доводите до того, чтобы их была половина работников и больше. Когда вы ставите планы, хотите достигнуть каких-то новых целей, эти пассажиры будут тянуть всю компанию вниз. И чем больше их становится, тем больше появляется негатива для разработчиков, которые заточены на максимальную эффективность, на повышение квалификации и так далее.
Пассажиров можно определить по соотношению стажа и знаний. Если, к примеру, стаж разработчика 6 лет, и он не знает обмены, то, скорее всего, это пассажир. Потому что за 6 лет разработчик, который хочет повышать свою квалификацию и свои знания, изучит те же самые обмены. Хороший разработчик знает новинки платформы, а пассажиры о новинках обычно не знают. Очень часто, когда у разработчиков пассажиров спрашиваешь, почему за 6 лет не изучен какой-то механизм, ответ у них один и тот же – не было такой задачи. Сильный специалист найдет задачу, будет изучать новые механизмы вне зависимости от того, есть у него задача или нет, ему просто это будет интересно. Пассажирам это неинтересно.
Если хотите двигаться вверх и вперед, лучше все-таки использовать героев и интровертов.
На этом у меня все. Если появятся какие-то вопросы, я могу рассказать более детально.
Большое спасибо!
Вопросы
- Как вы контролируете удаленных сотрудников? Не секрет, что у каждого опытного 1С-ника, как минимум, 1-2 своих клиентов, с которыми они приоритетно работают. Поэтому возникает много вопросов, когда надо выбрать между вами, удаленной работой, и своим клиентом, который требует выполнения.
- Когда мы принимаем на работу, я сразу доношу информацию, что мы работаем по 8 часов в день, мы всегда должны быть в онлайн, не должно быть такого, что 10-15 минут клиент не может достучаться до разработчика. Плюс наши клиенты сами могут оценить задачу. К примеру, если человек отработал 2 часа, а записал 8 часов, это могут оценить наши клиенты, можем оценить мы. И в этом случае мы просто сразу прощаемся.
- Но как именно вы их контролируете?
- Лично я каждое утро здороваюсь. Когда люди уходят на обед, они тоже отчитываются. И мне, и клиенту. Я объяснил уже, зачем нам это надо. Но в целом получается, что мы всех своих разработчиков подключаем напрямую к клиенту, и им задачи поступают в течение 8 часов все время. Куда-то отлучиться, переключиться на другую задачу нет возможности. Если человек переключится, то быстро возникнет вопрос, где разработчик, и даже если он окажется на связи, его всегда спросят, чем ты занимался.
- А как вы контролируете переход ваших сотрудников к клиенту непосредственно? Ведь, если клиент контролирует его, если он им доволен, то есть вариант предложить работать сразу на него.
- Насчет переманивания. Нашим разработчикам более комфортно и удобно работать лично со мной, в нашей компании. Потому что мы финансово стабильны, у нас хорошая зарплата, мы даем возможность заниматься только разработкой и работать в сильной команде. Если они переходят к другому клиенту, то я помешать этому никак не могу.
- Получается, что вы их уговариваете?
- Я их не уговариваю. Я просто предоставил им возможность заниматься своим любимым делом и получать хорошую заработную плату вовремя и стабильно. Плюс у нас всегда различные проекты. Если он уйдет к конечному клиенту, то, скорее всего, он не будет заниматься только разработкой. Его еще загрузят консультированием, обучением и так далее. И это будет один проект на долгие годы.
- Штрафы с клиентом вы проговариваете?
- Нет. Понимаете, если какие-то штрафы выставлять, это можно расценивать как нарушение прав самого сотрудника. Я не имею права препятствовать ему менять работу.
- Насколько я знаю, таким образом поступают аутсорсинговые компании, поэтому я и хотел уточнить.
- Я понимаю. Но у меня такого примера ни разу не было. Хотя были моменты, когда моим сотрудникам предлагали перейти, но сотрудники сразу мне сообщали, что их пытаются переманить.
- Скажите, у вас разработчики работают напрямую с конечным пользователем, консультантом от заказчика или у вас есть свои аналитики, консультанты?
- У меня свои консультанты-аналитики есть, но они тоже работают full-time. Разработчикам ставит задачи консультант или аналитик со стороны клиента. И я их не подключаю к конечным пользователям. У меня есть один клиент, где можно работать с конечными пользователями, но он только один. Дай бог таких клиентов всем и побольше.
- Какую схему мотивации вы используете: окладную, сдельную или окладно-премиальную?
- Оклад. Я им гарантировано всегда выплачиваю оклад, независимо от простоев. Простои и выработка – это все зависит от меня. Оплатил клиент или не оплатил – это опять же моя проблема, потому что я клиента привел.
- Никаких KPI, ничего такого нет?
- Нет. Но задача какая? Мы работаем максимально эффективно, клиентоориентированно, а если человек так не работает, то мы с ним просто прощаемся. У меня человек либо работает, либо не работает.
- Вы продаете клиентам конечные часы или готовый продукт?
- Часы.
- Правильно ли я понимаю, что если у вас не готов еще целиком какой-то механизм, который запросил клиент, счет ему будет выставлен все равно – на эти часы?
- Тут есть разные варианты. Если по оценке работать, тогда уже конечный результат идет. А если на full-time, как сейчас у нас, то оплачивается каждый час. Но если смотреть по оценке и по full-time, то лучше второй вариант – от разработчика эффективность выше. Потому что на него не давит эта оценка, сроки и так далее. Он в более расслабленном состоянии, он быстрее выполняет задачи.
- Как клиенты относятся к тому, что они оплачивают часы, а не готовые продукты? При этом у программиста, как я понимаю, нет особой мотивации быстрее завершать работу. Или это вообще не проблема?
- Это опять сводится к тому, что если человек не будет эффективно работать, то мы с ним просто не будем работать – он потеряет работу, финансовую стабильность и возможность заниматься любимым делом.
- А как оценивается эффективность? Вы знаете норму часов на каждую задачу или как?
- Скажем так: я сам в предыдущей кампании считался одним из самых сильных разработчиков и могу оценить работу и количество потраченных часов.
- Т.е. у вас 30 программистов, и вы за каждым следите? Или у вас есть какая-то система контроля эффективности? Я просто не понимаю. Если у них оклады, то за 30 работниками или больше следить как-то нереально.
- Наши клиенты – это фирмы франчайзи или крупные конечные клиенты, у которых есть свои отделы сопровождения и свои программисты, которые сами могут оценить эффективность. Если человек работает неэффективно, они мне об этом сообщат. Плюс каждый месяц я стараюсь брать у того или иного клиента отзыв по сотруднику, некий фидбэк. Иногда мы с разработчиком просто созваниваемся, обсуждаем, какая задача сейчас решается, сколько времени на это тратится. Иногда я могу попросить показать программный код, чтобы посмотреть, насколько грамотно человек пишет.
- Вы сказали, что у сотрудников только оклад, зачем тогда отмечать часы?
- Эти часы мы потом выставляем клиентам.
- В какой системе вы ведете учет задач?
- В 1С. Я наклепал по-быстрому.
- Когда разработчику поступает конкретная задача и ему необходимо уточнить постановку, как это происходит?
- Подключаем к клиенту. Постановкой задачи занимаются консультанты-аналитики. В основном нам все задачи ставят в устной форме, у нас нет опыта с ТЗ. Если разработчик видит какие-то неточности или ему что-то нужно прояснить, он обязательно сообщает об этом и уточняет задачу. Если он видит более оптимальные варианты, как сделать интереснее, он обязательно тоже их предлагает клиенту.
- Как вы планируете загрузку внешних разработчиков?
- У меня сейчас только одна проблема: где бы найти еще 10-15 разработчиков…
- А среди тех, что есть, как вы распределяете нагрузку, чтобы не было провалов по срокам?
- Они у меня находятся на full time, а проекты идут от нескольких месяцев до полугода. Есть клиенты, которые мне просто сказали: забудь про своих разработчиков, они с нами надолго.
- Я правильно понимаю, что вы работаете только с франчайзи, а с конечным пользователем фактически вы не работаете, он к вам не обращается?
- С конечными клиентами мы работаем, но работаем не для внедрения, а как сопровождение. Например, есть какая-то компания со своим штатом разработчиков. Допустим, один человек уволился, и им нужно закрыть эту дырку в кадрах. Они к нам обращаются. И также фирмы франчайзи, когда у них не хватает собственных ресурсов для проектов, а проектов сейчас много.
- А как вы в этом случае боретесь с «паранойей»? Потому что большинство компаний, особенно крупных, не готовы давать доступ к своим данным.
- Такая проблема бывает иногда. Были клиенты, которые предлагали такой заход в их сервер, что приходится работать на коленках. Разработчикам неудобно, и мы просто стараемся не работать с такими клиентами. Для меня разработчики очень важны, и мне важно, чтобы им работа нравилась. Но у большинства наших клиентов проблем с этим нет, они спокойно предоставляют доступ к серверам или к какому-то рабочему месту, где наши разработчики уже работают.
****************
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.
