Как стать автором
Обновить

Комментарии 26

автоматическим расчётом коэффициентов эффективности конкретного сотрудника

поделитесь мыслями по этому поводу, очень интересно как кто считает.
Сейчас вся аналитика строится на нескольких показателях:
  1. Мы ведём учёт часов, затраченных на каждую задачу
  2. Настаиваем (пока с переменным успехом:) на даче предварительных оценок по задачам в соответсвующем поле в redmine
  3. Имеем вычисленные рейты каждого сотрудника на основе его зарплаты и аммортизированных на всех общих тратах
  4. Имеем рейты с клиентами, зафиксированные в редмайне и бюджет по каждому проекту
  5. В конце месяца начальники отделов по мере сил готовят эффективные часы по каждому сотруднику
  6. Есть бюджеты на отдел и в конце месяца становится понятно, насколько они перекрыты и сколько реальной прибыли принёс, например, отдел дизайна


На основе этих данных уже можно понять, выгоден ли каждый конкретный проект (даже просто рейт клиента), эффективен ли разработчик, точен ли он в оценках. Конечно по сути сейчас это всего лишь параметры. Подставлять их в формулы (в том числе и зарплатные) приходится вручную. И я вижу массу вариаций автоматического подсчёта, а также внесения новых показателей. Ну и графики всякие наглядные были бы весьма к месту.
Вот есть сотрудник, по каким-то расчётам и показателям менеджеров, он имеет максимальную полезную отдачу 5 часов в сутки или 2 часа в сутки в режиме «мозгового штурма». Вы его выгоните? Вы думаете можно «выжимать» больше?
Есть понимание, что хорошая эффективность — это 4 полных рабочих часа из 7 (у нас кстати семичасовой рабочий день, а не восьми).
Отличная эффективность — 5 рабочих часов из 7. Это не значит, что человек 2 или 3 часа валяет дурака, но очевидно, что есть определённое количество времени, нужное на то, чтобы войти в поток, есть перекуры, походы в туалет, заход на ту же хабру или fb, чтобы немного расслабить мозг. Всё это понятно и совсем не повод для увольнения. Но точно так же довольно очевидно, что отчёты в стиле «я 10 часов искал подходящие картинки для заполнения сайта тестовым контентом» — это не эффективная работа, особенно если на задачу было отведено 2 часа или вообще такой задачи не было в плане.

Не понимаю, почему хабражители испытывают такую фрустрацию при попытке оценить их эффективность? Ясно же, что строки кода не показатель. Но хороший программист вполне способен оценить как архитектурную реализацию, так и чистоту, понятность, документированность кода. Уж не синдром ли это «вора», на голове которого шапка горит?
Суть статьи — «как мы все делаем стандартно». Вот была-бы у вас интересность какая-нибудь, а то коэффициенты на сотрудников, эффективности по строчкам кода да и даже IDE у всех одна — совсем скучно. Зачем разработчиков так контролировать и ограничивать? Дайте им хотя бы инструменты разработки, в которых работать будут только они выбирать им самим.
Я до того, как занялся бизнесом успел поработать в двух компаниях и ещё про процессы в добрых 5-6 слышал/видел. Почему-то нигде такого «стандарта» не было. Да и примени мы его год назад — кто знает, не было бы у нас сейчас 120 человек вместо 40.
Я не в пику тому, что «нифигасебеинновация», но к тому, что не всё на самом деле так очевидно. Многие вещи тестируются до сих пор, какие-то подходы отмирают, другие приживаются.
Уже сейчас мы склоняемся к уменьшению значения «отработанных» часов в пользу повышения эффективности закрытия задач. Да и те же начальники отделов у нас заполняют только часы по программированию (если оно у них есть).
Как долго длится у вас проект в среднем? Я о том, что то, что хорошо подходит для коротких и среднесрочных проектов абсолютно не подходит для длительных.
По-разному. Есть проекты на неделю, есть такие, которым уже больше года.
Удобно в общем-то для всех — если разделять вывод задач фильтрами и интерациями. Ну и как раз для долгих проектов с ротацией команды интегрированная вики, вся переписка с клиентами, сделки и инвойсы — очень помогает.
Есть, конечно, претензии к редмайну. Не всё идеально. Но пока ничего более подходящего нашим нуждам не попалось.
>эффективности по строчкам кода
Не надо меня перевирать) Про строчки кода не было ни слова. Эффективность измеряется в часах.
Несколько человек, сумевшие обосновать необходимость работы в других IDE работают в них. Особенно это касается программистов ранга advanced+ — им-то в редактор никто не полезет, скорее наоборот. Хотя и их мы стараемся склонять всё-таки к PHPStorm. Ибо стандартизация творит чудеса, к тому же для PHP это по моему скромному мнению один из лучших вариантов IDE.
НЛО прилетело и опубликовало эту надпись здесь
К сожалению у нас далеко не все используют выкладку на dev-сервер через GIT. Мы довольно активно её внедряем, но людей много и многих надо убеждать, а некоторых обучать (например верстальщиков) — так что процесс идёт не быстро.
А что за CRM используется с Redmine?
Благодарю, но я хотел, что бы это сказал автор…
Тогда следующими моим вопросами были бы «А рассматривались ли какие-то альтернативы?» и «Какие общие впечатления от Redmine CRM?».
Семён, подтверждаю. Не хотел давать ссылки, чтобы не сочли за рекламу.
Мы пробовали…. Ух. Целую кучу всего.
Весной 2012 мы работали с redmine, но нам не хватало CRM-функционала.
В мае 2012 мы воспользовались Мегапланом (самым крутым пакетом) — всё, что касается расходов и ЗП было супер, CRM был плюс-минус удобный, трекер задач совершенно неудобный. Именно представление списка — как дерево, так и табличное представление. Ну и цена за систему, которая не удовлетворяла нас на 100% была достаточно большой.
Затем мы перешли на planfix — в целом функционал расходов и счетов был понятный, CRM средненький (даже слабый на тот момент), таск-трекинг был неудобный. И самое главное — он жутко тормозил периодически. И иногда даже падал
Параллельно мы работали во Wrike (и одного клиента до сих пор ведём там) — самый удобный таск-трекер. Но на единую систему для IT-компании к сожалению не тянет.
Следующей системой (примерно сентябрь-октябрь 2012) был www.birdviewprojects.com Им мы пользовались чуть больше месяца. Затем мы окончательно устали, изучили ещё 3-4 системы, смотрели и в сторону saleforce как CRM и на американские системы. В итоге купили плагин CRM, Invoices и вернулись в редмайн. Счастью не было предела) Оказалось, что как таск-трекер он самый-самый, а то, что даёт CRM+Invoices покрывает наши нужды процентов на 70. Аналитика и заплаты остались за бортом, я сам накропал для этого на fuel-php небольшую систему учёта и в общем-то творческий поиск остановился.
Странно, что в этом списке нет Jira.
Сергей, большое спасибо за ссылки на наши плагины. У нас еще много планов на будущее и мы будем стараться покрыть все основные бизнес процессы web-студий и в целом IT компаний небольшого и среднего размера. Скоро можно будет настраивать шаблоны счетов и управлять сметами (estimates). И еще у нас на выходе новый плагин Products который поможет вести учет заказов и продуктов.

Кстати, в выходные вышли новые версии для CRM, Invoices и Finance. В CRM добавился новый вид отображения сделок в виде Доски/Pipeline а в Invoices появилось новое состояние Estimate для учета Смет

К тому же, мы всегда отрыты для новых идей и с радостью выслушаем предложения и замечания!
Важный момент. Так и не получил комментариев, нужно ли разворачивать тему дальше. Рассказывать про штатное расписание более подробно, акцентировать внимание на ошибках, которые заставили принять то или иное решение?
В общем, если вам это интересно — дайте знать, всё-таки подготовка статьи — не 5 минут времени, хотелось бы заниматься тем, что приносит другим пользу ;)
рассказывайте о штатном расписании и ошибках, конечно же
Расскажите подробнее про то, как именно из гаражной студии вы выросли в 8 раз. Сколько учредителей, как наполнялись кадрами. Действительно, самое интересное осталось за бортом статьи: динамика развития, какая тактика и стратегия развития были выбраны и почему.
Думаю, об этом будет либо следующая, либо 3я часть статьи.

Пока же могу сказать, что учредителей двое (я и мой друг), начальный капитал — порядка $2500, первый состав — пять человек (со-учредители и три сотрудника). Динамика роста — примерно по 2-3 человека в месяц. Сейчас стабилизируем бизнес-процессы компании и приостановили рост. Опыта, конечно, за эти полтора года столько, что можно уже книги писать, не то, что статьи :) Какие-то ошибки и решения были хрестоматийными, какие-то — импровизацией и даже местами банальной глупостью, но в целом теперь развиваться куда легче, самый сложный этап уже позади.
Отличная статья!

Обящательно нужно продолжать и рассказывать дальше.

То, что кажется очевидным многим комментаторам — как правило, совсем не очевидно и при внедрении заняло много сил, нервов, денег и времени.
Например, у себя мы тоже выстраиваем бизнес-процессы, и к имеющимся в настоящий момент мы пришли не так быстро, как хотелось бы, а методом проб и ошибок.

Очень интересует способы расчета зарплаты и учет такой ситуации:
«Разработчик сделал задачу быстрее, но потом затратил время на исправление багов». Как вы поступаете в этом случае?
Рассказывайте, интересный материал. Если поделитесь, как организовываете продажи (план продаж, источники клиентов) и об маркетинговом позиционировании, вообще будет супер :)

Дополнительно хотелось бы узнать:
1. Redmine Wiki

Сейчас тоже пытаюсь ее использовать, но иногда выглядит не очень функциональной/удобной. Возможно, расширяете ее какими-то плагинами или используете особые приемы организации wiki?

2. Не задумывались об организации общей базы знаний по компании? Потому что вики по каждому проекту – это одно, но часто есть какие-то общие наработки, внутренние стандарты, это тоже было бы неплохо систематизировать.
.
Обязательно расскажу.
1. Есть шаблоны, помогающие быстро заполнить Wiki проекта
2. Поставили плагин, который создаёт общую базу знаний вне проектов.
Сергей

хотелось бы услышать как в вашей компании идет распределение финансов,

зп, бонусы руководителей отделов. программистов, прибыль компании

чтобы не раскрывать ком тайну (а то вдруг )), можно в процентном соотношении

присоединяюсь к dfn «Рассказывайте, интересный материал. Если поделитесь, как организовываете продажи (план продаж, источники клиентов) и об маркетинговом позиционировании, вообще будет супер :)» — очень интересный материал

в комментах много хороших вопросов, если большую часть осветить получиться очень хороший кейс по организации работы веб студии
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории