Я полностью согласен, что риски при создании чего-то нового высоки и неизбежны. И это верно не только для стартапов, но и для крупных компаний. А у крупной компании, выигрывающей огромный тендер на, например, строительство не имеющего аналогов сооружения, риски будут посерьезнее, чем у стартапа из четырех человек.
Просто можно сказать клиенту — «вы знаете, мы конкретно этого никогда не делали (или — никто этого никогда не делал), но у нас есть такие-то компетенции, такие-то ресурсы, и мы готовы взяться за эту работу и вложиться в нее по полной, потому что она очень для нас важна». А гибкость и готовность вкладываться (читай «много работать бесплатно») — это важное преимущество в глазах клиента. Это честный подход, и клиент может сделать осознанный выбор и заранее приготовиться к тому, что что-то не получится, подложить подушку.
А можно сказать — «да не вопрос, все сделаем — мы таких проектов по 7 штук в неделю делаем». И клиент уверен, что все будет нормально, запасной аэродром не готовит, а потом в день сдачи попадает в беду. Причем возможно, что более серьезную, чем исполнитель.
Смотря что вы понимаете под словом «героизм» :) Если работу по 16 часов в день, то у меня здесь следующее мнение. Конечно, если хочешь чего-то добиться, работать нужно много — и не в стартапе тоже. А вот скорость нужно выбирать ту, которую можешь поддерживать долго. Это как в альпинизме — на вершины заходят не те, кто бежит впереди всех, а те, кто долго держит свой темп.
Что толку, если ты выкладываешься до полного нуля, запуская какой-то стартап? Потом откуда брать силы для поддержки и развития своего проекта, если дело пойдет? С первой версией же работа не заканчивается, а только начинается. И откуда брать силы делать что-то другое, если не пойдет?
Думаю, что это разные вещи — брать на себя ответственность и риски (это бизнес, конечно, должен делать), а другое дело врать заказчику.
У меня тоже в жизни были ситуации, когда клиенту сказали, что все готово, а потом сами в мыле, в поте ночами доделываем (и, кстати, от размера бизнеса это не зависит). И когда все сделали и успели — вроде как герои. Только потом я понял, что этот героизм в 95% случае возникает на пустом месте из-за собственного раздолбайства, и ничего хорошего в нем нет. Что можно заранее сказать «нет» и предупредить о рисках клиента. Что можно все продумать и запланировать, в том числе и планы Б, В и так далее. И что можно не гонять инженеров ночами, а получать лучшие результаты за меньшие деньги.
Ну и самое главное, что после такого «успешного» «мероприятия» нужно не открывать шампанское и радоваться, а сесть и сказать: «Блин, ребята, ну в это раз пронесло. Давайте думать, как сделать так, чтобы в будущем такого не случилось».
Если вы говорите о ночном расщеплении белков в мышцах, которое происходит в голодном организме, то это верно. Хотя, на мой взгляд, это критично в первую очередь для тех, кто работает на мышечную массу (а это далеко не все, кто занимается спортом).
Я, может, излишне категорично выразился, но я имел ввиду, что не нужно именно наедаться. А поесть чуток казеиносодержащих продуктов, типа творога, которые будут ночью медленно снабжать энергией организма — почему нет?
А с тем, что надо в принципе следить за своим питанием, полностью согласен — но это уже отдельный обширный вопрос за пределами данной темы.
Может быть, я скажу банальность, но я вот смог нормально вставать рано утром только после того, как перестал, простите, жрать после 21.00. Вроде бы такое простое действие, а мгновенно начинаешь лучше высыпаться (потому что вся пищеварительная система отдыхает ночью) и начинаешь легко рано вставать (потому что голод будит). И после этого же я перешел на плотные ранние завтраки, а это реально залог производительности в течение дня. Раньше мог первый раз поесть только часов в 11, а до этого времени работоспособность была минимальная.
То есть если в команде все работают примерно одинаково, то нет разницы, насколько велика производительность команды в целом — бонусы все равно все получат такие же? Я считаю, что команда должна быть нацелена в целом на результат — а уж они сами пусть разбираются, кто молодец, а кто тянет всех на дно. У меня подход такой — провалили спринт — ответственность тимлида. Кто-то там что-то не сделал? Ничего не знаю — ты набираешь команду и отвечаешь за нее и за результат. Уволь, возьми другого. Конечно, чтобы такой подход работал, тимлид должен иметь соответствующие полномочия. А для внутренних разборок в команде хорошо работает метод ретроспективы, который помогает сосредоточиться на решении проблем, а не на взаимных обвинениях.
Кстати, сделанными задачи у нас считаются тогда, когда они оттестированы, а найденные critical и major баги исправлены. Еще важно ставить критерии выполнения задачи, иначе при сдаче спринта тоже много эмоций возникнуть может.
Это интересно, хотя буду честен, верится мне с трудом. А если не секрет, какой в среднем процент от совокупного дохода на руки составляют бонусы (за год, например)? И как вы определяете факт, что система работает?
Точность оценок трудоемкости задач разработки (а точнее, ее отсутствие) — это отдельная тема для разговора. Но даже если предположить, что такие оценки в вашем случае существуют (я немного пофантазирую), то как только к ним будут привязаны значимые для людей бонусы, возникнет обратная связь, влияющая на оценки. Вместо того чтобы работать, люди начнут оптимизировать и продавливать оценки, которые им нужны для бонусов. Придется дорабатывать систему бонусов до тех пор, пока рядовые сотрудники вообще не перестанут понимать, как рассчитывается их доход, а руководителям придется тратить половину времени на доработку и контроль системы метрик.
Я, конечно, немного утрировал, но мысль, думаю, ясна. Я бы не посоветовал внедрять такую систему. В любом случае, лучший судья в этом деле — практика, а решение за вами — попробуйте, расскажете через полгода-год, что получилось.
Я бы разделил обсуждение на две темы — метрики и бонусы (хотя эти темы часто связывают).
1. Метрики. Безусловно, производительность разработчиков оценивать нужно. И руководство компании, и непосредственный руководитель, и самое главное, сам разработчик должны понимать, насколько хорошо/плохо он справляется со своими задачами и достигает своих целей. Вот только работающих KPI для разработчиков еще никто не придумал. Почему это так — тема слишком общирная для обсуждениях в комментариях. Это хорошо изложено у классиков, таких как ДеМарко, Листер, Брукс и т.п., и весь мой личный опыт и опыт коллег это подтверждает. И даже тот факт, что в некоторых компаниях метрики используются, доказывает, на мой взгляд, лишь то, что метрики могут в лучшем случае не мешать.
2. Бонусы. Я считаю, что бонусы для разработчиков оправданы только в том случае, когда их производительность четко связаны с финансовым результатом. А это бывает крайне редко и применимо только для индивидуальных разработчиков и очень маленьких команд, готовых брать на себя бизнес-риски. Потому что в команде из 5-10 человек, работающих над одним проектом, уже невозможно выделить вклад каждого (потому что метрик не существует). Да и финансовый результат уже зависит не только от разработчиков, но и от продажников, менеджеров, да и просто от ситуации на рынке (а это вообще случайный фактор). Вот и получается, что бонусы становятся неиссякаемым источников демотивации и несправедливости. Я считаю, что разработчикам необходимо обеспечивать достойную, честную зарплату для их уровня профессионализма. Ну может, с возможностью депремирования за серьезные нарушения дисциплины (у меня такое в практике понадобилось один раз). Также нужно давать четкую обратную связь, четкое понимание целей и давать возможность развития (с бонусами это уже не связано). И как раз для этого нужен сильный непосредственный руководитель (потому что метрики, опять же, не работают).
Мой опыт работы руководителем центра разработки показывает, что любые синтетические методики оценки не работают эффективно. Они либо требуют неоправданного расхода ресурсов на поддержание, либо становятся источником демотивации.
Я не вижу решения, кроме как построить вертикаль руководителей команд, групп и т.п. Так, чтобы каждый руководитель на своем уровне знал и понимал своих подчиненных (не более 7-8 человек) и мог грамотно их мотивировать (как материально, так и нематериально). Для этого руководитель должен быть именно руководителем, а не просто самым лучшим кодером.
А систем расчета бонусов можно много придумать, только лично я не поверю, что они работают без чистого продолжительного положительного опыта (на протяжении более года минимум).
Это верно, но самым сложным будет добиться собственно решения ВАКа. Хотя, наверное, это не невозможно. Может быть у кого-нибудь есть там контакты, подбросить идею? Ну и инициатива, конечно, должна исходить от Тематических Медиа.
Мне кажется, давно пора статью на хабре приравнять к ВАКовской публикации. Можно отдельный хаб для этого создать, а еще ввести специальную «научную» карму :)
Кстати, у меня была похожая ситуация. Сеть с полностью заблоченным Интернет, в которой работал скайп и больше ничего. Я тогда предположил, что в этой же подсети есть компьютер, которому доступ в Интернет разрешен, и на котором скайп запустился в режиме супернода. Было же blackbox исследование, что по крайней мере до покупки скайпа Microsoft'ом, обычный скайп мог запускаться на компьютере пользователя как супернод и роутил информацию через себя, если детектил хорошие ресурсы компа и канал.
Очень интересная информация про технологию «конвертирования» VP8<->H.264 на лету. Сколько по вашим оценкам таких транскодирований может тянуть одно ядро среднего процессора типа i7?
Да, все верно, роли бизнес-аналитика и Product Manager сильно пересекаются. Разница лишь в том, что Product Manager еще и отвечает за выполнение разработки при заданных ограничениях ресурсов и стратегию развития продукта (мне показалось, что для автора поста это также важно). Вот, украду сюда хорошую картинку для иллюстрации роли Product Manager.
На самом деле, все эти определения ролей довольно условны. Понятно, что хороший программист должен быть еще и немного бизнес-аналитиком, а хороший бизнес-аналитик немного программистом — то есть один человек должен сочетать в себе несколько ролей. Просто концепция роли Product Manager хорошо подходит для компании, которая разрабатывает свой продукт. А роль бизнес-аналитика в широком понимании востребована в компании аутсорсере или интеграторе. А по факту это может быть один и тот же человек, конечно.
Ваше описание, как мне кажется, все-таки более широко, чем роль бизнес-аналитика. Скорее оно соответствует роли Менеджера по управлению продуктом (Product Manager) в контексте методологии NPD, например.
На русском языке не там много информации по этой роли, на самом деле. Единственный, кто этим вообще занимается в РФ, по-моему, это Дмитрий Безуглый. Я был в свое время на его тренинге по управлению продуктами, и это оказалось хорошим подспорьем в дальнейшей работе.
А на английском языке много хороших статей есть здесь — www.svpg.com. Это блог группы Марти Кагана, автора замечательной книги «Inspired: How To Create Products Customers Love». Эта книга как раз для тех, кого вы описали в своем посте.
Спасибо! Скину нескольким своим знакомым «квантам». Хотя на ликбез статья и правда не тянет, но очень хорошо доносит главную мысль — если ты не занимаешься трейдингом профессионально (профессионально, это в плане формирования рынка) — не лезь. Если, конечно, не хочешь просто поиграть «в рулетку», что само по себе, может быть, и неплохо — главное, себя не обманывать, что ты, типа, «зарабатываешь».
Интересно, насколько эта статья негативно повлияет на количество «хомячков» в системе, и, в частности, «квантов», которых, наверное, в аудитории хабра побольше в относительном отношении.
Просто можно сказать клиенту — «вы знаете, мы конкретно этого никогда не делали (или — никто этого никогда не делал), но у нас есть такие-то компетенции, такие-то ресурсы, и мы готовы взяться за эту работу и вложиться в нее по полной, потому что она очень для нас важна». А гибкость и готовность вкладываться (читай «много работать бесплатно») — это важное преимущество в глазах клиента. Это честный подход, и клиент может сделать осознанный выбор и заранее приготовиться к тому, что что-то не получится, подложить подушку.
А можно сказать — «да не вопрос, все сделаем — мы таких проектов по 7 штук в неделю делаем». И клиент уверен, что все будет нормально, запасной аэродром не готовит, а потом в день сдачи попадает в беду. Причем возможно, что более серьезную, чем исполнитель.
Что толку, если ты выкладываешься до полного нуля, запуская какой-то стартап? Потом откуда брать силы для поддержки и развития своего проекта, если дело пойдет? С первой версией же работа не заканчивается, а только начинается. И откуда брать силы делать что-то другое, если не пойдет?
У меня тоже в жизни были ситуации, когда клиенту сказали, что все готово, а потом сами в мыле, в поте ночами доделываем (и, кстати, от размера бизнеса это не зависит). И когда все сделали и успели — вроде как герои. Только потом я понял, что этот героизм в 95% случае возникает на пустом месте из-за собственного раздолбайства, и ничего хорошего в нем нет. Что можно заранее сказать «нет» и предупредить о рисках клиента. Что можно все продумать и запланировать, в том числе и планы Б, В и так далее. И что можно не гонять инженеров ночами, а получать лучшие результаты за меньшие деньги.
Ну и самое главное, что после такого «успешного» «мероприятия» нужно не открывать шампанское и радоваться, а сесть и сказать: «Блин, ребята, ну в это раз пронесло. Давайте думать, как сделать так, чтобы в будущем такого не случилось».
Я, может, излишне категорично выразился, но я имел ввиду, что не нужно именно наедаться. А поесть чуток казеиносодержащих продуктов, типа творога, которые будут ночью медленно снабжать энергией организма — почему нет?
А с тем, что надо в принципе следить за своим питанием, полностью согласен — но это уже отдельный обширный вопрос за пределами данной темы.
То есть если в команде все работают примерно одинаково, то нет разницы, насколько велика производительность команды в целом — бонусы все равно все получат такие же? Я считаю, что команда должна быть нацелена в целом на результат — а уж они сами пусть разбираются, кто молодец, а кто тянет всех на дно. У меня подход такой — провалили спринт — ответственность тимлида. Кто-то там что-то не сделал? Ничего не знаю — ты набираешь команду и отвечаешь за нее и за результат. Уволь, возьми другого. Конечно, чтобы такой подход работал, тимлид должен иметь соответствующие полномочия. А для внутренних разборок в команде хорошо работает метод ретроспективы, который помогает сосредоточиться на решении проблем, а не на взаимных обвинениях.
Кстати, сделанными задачи у нас считаются тогда, когда они оттестированы, а найденные critical и major баги исправлены. Еще важно ставить критерии выполнения задачи, иначе при сдаче спринта тоже много эмоций возникнуть может.
В любом случае — вам успехов!
Я, конечно, немного утрировал, но мысль, думаю, ясна. Я бы не посоветовал внедрять такую систему. В любом случае, лучший судья в этом деле — практика, а решение за вами — попробуйте, расскажете через полгода-год, что получилось.
1. Метрики. Безусловно, производительность разработчиков оценивать нужно. И руководство компании, и непосредственный руководитель, и самое главное, сам разработчик должны понимать, насколько хорошо/плохо он справляется со своими задачами и достигает своих целей. Вот только работающих KPI для разработчиков еще никто не придумал. Почему это так — тема слишком общирная для обсуждениях в комментариях. Это хорошо изложено у классиков, таких как ДеМарко, Листер, Брукс и т.п., и весь мой личный опыт и опыт коллег это подтверждает. И даже тот факт, что в некоторых компаниях метрики используются, доказывает, на мой взгляд, лишь то, что метрики могут в лучшем случае не мешать.
2. Бонусы. Я считаю, что бонусы для разработчиков оправданы только в том случае, когда их производительность четко связаны с финансовым результатом. А это бывает крайне редко и применимо только для индивидуальных разработчиков и очень маленьких команд, готовых брать на себя бизнес-риски. Потому что в команде из 5-10 человек, работающих над одним проектом, уже невозможно выделить вклад каждого (потому что метрик не существует). Да и финансовый результат уже зависит не только от разработчиков, но и от продажников, менеджеров, да и просто от ситуации на рынке (а это вообще случайный фактор). Вот и получается, что бонусы становятся неиссякаемым источников демотивации и несправедливости. Я считаю, что разработчикам необходимо обеспечивать достойную, честную зарплату для их уровня профессионализма. Ну может, с возможностью депремирования за серьезные нарушения дисциплины (у меня такое в практике понадобилось один раз). Также нужно давать четкую обратную связь, четкое понимание целей и давать возможность развития (с бонусами это уже не связано). И как раз для этого нужен сильный непосредственный руководитель (потому что метрики, опять же, не работают).
Я не вижу решения, кроме как построить вертикаль руководителей команд, групп и т.п. Так, чтобы каждый руководитель на своем уровне знал и понимал своих подчиненных (не более 7-8 человек) и мог грамотно их мотивировать (как материально, так и нематериально). Для этого руководитель должен быть именно руководителем, а не просто самым лучшим кодером.
А систем расчета бонусов можно много придумать, только лично я не поверю, что они работают без чистого продолжительного положительного опыта (на протяжении более года минимум).
На самом деле, все эти определения ролей довольно условны. Понятно, что хороший программист должен быть еще и немного бизнес-аналитиком, а хороший бизнес-аналитик немного программистом — то есть один человек должен сочетать в себе несколько ролей. Просто концепция роли Product Manager хорошо подходит для компании, которая разрабатывает свой продукт. А роль бизнес-аналитика в широком понимании востребована в компании аутсорсере или интеграторе. А по факту это может быть один и тот же человек, конечно.
На русском языке не там много информации по этой роли, на самом деле. Единственный, кто этим вообще занимается в РФ, по-моему, это Дмитрий Безуглый. Я был в свое время на его тренинге по управлению продуктами, и это оказалось хорошим подспорьем в дальнейшей работе.
А на английском языке много хороших статей есть здесь — www.svpg.com. Это блог группы Марти Кагана, автора замечательной книги «Inspired: How To Create Products Customers Love». Эта книга как раз для тех, кого вы описали в своем посте.
Интересно, насколько эта статья негативно повлияет на количество «хомячков» в системе, и, в частности, «квантов», которых, наверное, в аудитории хабра побольше в относительном отношении.
Такой бы на русском — студентам и школьникам бы очень пригодилось (да и преподавателям, как образец). Может быть, есть что-то такое?