Человеческий мозг разумно ленив. И требование дать оценку в часах — один из трюков, чтобы заставить его поверить, что все серьезно и надо поработать над решением, а не дать формальную отписку.
Если вы не успеете сделать «до конца недели» всего одну из десятка задач «поменяй текстовку» просто потому, что плохо спланировались, вы можете запросто слить рекламный бюджет в несколько своих месячных зарплат просто потому, что дорогой лид пришел на страницу, где он не увидел отражения своей потребности. И ушел :)
В крупных проектах сроки могут сколько угодно спускаться сверху, но физику не обманешь и бизнесу лучше узнать горькую правду о том, что в эти сроки можно сделать только 1/3 требуемого до того, как он подпишет контракт с серьезными неустойками за срыв сроков)
Максим, я прочитал статью и не на один раз. И мы можем предметно и аргументированно пообщаться, хотя я и очень зол на вас за такое отношение к мотивации команд в моем все еще любимом Контуре :)
Если суммировать:
1. Противопоставление сроков поставки и оценки сложности задач в часах — абсолютно искусственное именно в продуктовой разработке. Это изоморфные вещи. В заказной разработке человекочасы переводятся еще и в деньги, но в вашем случае это чистая манипуляция. Вместо того, чтобы спросить: «Ты же обещал к четвергу, а сегодня пятница. Где?!» — владелец продукта спросит: «Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
2. Завышение оценок специалистами. Такая проблема есть, но решается она не отказом от оценки, а методами коллективной оценки, когда завышенная оценка не проходит дизайн-ревью, и ежедневных летучек, которые в нормально мотивированной команде не дают зря проедать временной бюджет.
3. Негативное влияние оценки на производительность. Если я правильно помню, ДеМарко писал об этом в контексте травли команд. Правильная оценка задач, как вы и сами пишете ниже, позволяет достаточно детализировать задачу, привлечь коллективное знание всей команды, чтобы не допустить большей части возможных дорогостоящих ошибок, которые один человек допустил бы, не допустить чрезмерного раздувания оценки — и получить достаточно надежные оценки, чтобы с высокой точностью планировать выпуски.
4. Самое главное. Предлагаемый вами подход убивает мотивацию сотрудников, потому что убивает вовлеченность в жизнь своего продукта и в принятие решений. Чувство сопричастности судьбе своего продукта и чувство личной ответственности за качество и за собственноручную оценку сроков — важнейшие мотиваторы разработчиков. Когда работа разработчика превращается в смену у конвеера с тасками, а сверху на него валятся взятые с потолка кем-то сроки, даже самая мотивированная команда необратимо превращается в болото. Что вы, к сожалению, вероятно, нередко видите вокруг :)
Без оценки сроков бизнес просто умрет. Попробуйте, например, сказать маркетологам, что вы понятия не имеете, к какому сроку нужно подготовить и запустить многомиллионную рекламную кампанию или пообещать выпустить фичу к текущему пику отчетности, а выпустить через неделю после этого :)
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.
Если бы автор работал в заказной разработке, где бюджет может быть важнее сроков, а время выполнения задачи переводится не только в сроки, но и в деньги, это противопоставление имело бы смысл. Иногда заказчику выгоднее делать дольше, но дешевле.
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
Поэтому противопоставление оценки сроков и оценки трудозатрат в часах — это неловкая манипуляция со стороны автора.
На месте руководителей Контура я бы поставил вопрос о снятии автора с должности за профнепригодность :)
Когда в нормальной команде от разработчика (тестировщика) требуют оценки сроков выполнения задачи, от него ждут двух вещей:
1. Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете. Такой детальный разбор задачи на этапе планирования делается не индивидуально, а в команде. Он позволяет не делать фигни и заодно получить реалистичную оценку сроков выполнения (которая фиксируется в том же тикете).
2. Взятия на себя ответственности за заявленные сроки. Когда задача уже разобрана и решение понятно описано, команда и отдельный разработчик с открытыми глазами берет на себя ответственность за сроки. Это порождает совсем другое отношение к работе, чем спускаемые сверху непонятные, а иногда и безумные сроки от «менеджеров».
Потом из таких качественно предобработанных задач легко собираются управляемые итерации скрама.
Именно такие граждане сначала не требуют от разработчиков оценки задач, перевешивают ее на менеджеров, у которых должны быть совсем другие компетенции, а потом жалуются, что у них «скрам не работает».
Пишу как человек, полтора года руливший невероятно бодрой командой разработки из бывших сотрудников Контура, которая с этим подходом запилила качественный продукт и всегда соблюдала сроки поставки. Не сдержался :)
А можете поделиться статистикой по платным фичам, какой процент пользователей базовой телефонии пользуется этой фичей? :)
Почему-то мне кажется, что подавляющее большинство из ваших тысяч пользователей жмется покупать дополнительные возможности, а потому пользуется весьма бедной функциональностью. Потому что SMB никогда не купит для своего удобства то, что можно не покупать.
Прибыль — это прекрасно. Работать без прибыли — аморально. Проблема в том, что вы за абсолютно стандартные для всех бесплатных АТС фишечки хотите столько же денег, сколько я за всю связь плачу с нескольких номеров :)
Не поленился связаться с техподдержкой и дождаться оператора.
И таки да, TLS и SRTS у Манго включить нельзя. Пароль для подключения к учетке стыдливо прикрывается жиденьким MD5 и хэш гоняется в открытом виде. Голосовой трафик может слушать любой желающий.
А еще, я правильно понимаю, что при подключении к вашей виртуальной АТС SIP-софтфонов никак нельзя включить TLS и SRTS? А значит, нельзя безопасно совершать звонки из недоверенной сети?
Суть моего комментария с технической точки зрения сводится к тому, что виртуальная АТС от Манго по функциональности — как бесплатная веб-обертка над Астериском. Только у вас она не бесплатная :)
Все это классно, конечно. Но зачем вы такие крохоборы?
Сейчас я плачу 740 р./мес. за лицензию на вирутальную АТС (то есть, считая без номеров и звонков).
Если я включу у вас такие базовые вещи как черный список, запись разговоров с хранением в пределах 5ГБ, минимальные конференции, мониторинг и API, то я буду платить примерно 3 500 р./мес. за ваш супер-функциональный облачный софт.
Если остаться на минимальном тарифе и развернуть на облачной виртуалке за 300 р./мес. абсолютно бесплатный Asterisk, то даже если отдать за его настройку 15к, замена вашей нарезки функций окупится за полгода.
И никаких ограничений по количеству пользователей, записи звонков, конференциям, схемам переадресации и возможностям интеграции. И это при использовании вашей же телефонии.
Захожу на страницу с фичами сервиса и вижу просто крутейшую функциональность: «Выписки глубиной до 5 лет». Блин. Посадите разработчиков сделать фичу «Все выписки за любой период с момента открытия счета всегда безусловно любой ценой», а уже потом можно будет про разное юзабилити подумать.
Главный вопрос для любого, кто хочет делать финтех-стартап не в том, купит ли его какой-нибудь банк, а в том, почему банки не посморят на донора хороших идей, и не реализуют их сами :)
Ваш вариант, на самом деле, эквивалентен, потому что при наличии такого плана работ и дать оценку сроков — уже не проблема.
В крупных проектах сроки могут сколько угодно спускаться сверху, но физику не обманешь и бизнесу лучше узнать горькую правду о том, что в эти сроки можно сделать только 1/3 требуемого до того, как он подпишет контракт с серьезными неустойками за срыв сроков)
Если суммировать:
1. Противопоставление сроков поставки и оценки сложности задач в часах — абсолютно искусственное именно в продуктовой разработке. Это изоморфные вещи. В заказной разработке человекочасы переводятся еще и в деньги, но в вашем случае это чистая манипуляция. Вместо того, чтобы спросить: «Ты же обещал к четвергу, а сегодня пятница. Где?!» — владелец продукта спросит: «Ты же обещал сделать за 9.5 календарных часов и начал позавчера. Где?!».
2. Завышение оценок специалистами. Такая проблема есть, но решается она не отказом от оценки, а методами коллективной оценки, когда завышенная оценка не проходит дизайн-ревью, и ежедневных летучек, которые в нормально мотивированной команде не дают зря проедать временной бюджет.
3. Негативное влияние оценки на производительность. Если я правильно помню, ДеМарко писал об этом в контексте травли команд. Правильная оценка задач, как вы и сами пишете ниже, позволяет достаточно детализировать задачу, привлечь коллективное знание всей команды, чтобы не допустить большей части возможных дорогостоящих ошибок, которые один человек допустил бы, не допустить чрезмерного раздувания оценки — и получить достаточно надежные оценки, чтобы с высокой точностью планировать выпуски.
4. Самое главное. Предлагаемый вами подход убивает мотивацию сотрудников, потому что убивает вовлеченность в жизнь своего продукта и в принятие решений. Чувство сопричастности судьбе своего продукта и чувство личной ответственности за качество и за собственноручную оценку сроков — важнейшие мотиваторы разработчиков. Когда работа разработчика превращается в смену у конвеера с тасками, а сверху на него валятся взятые с потолка кем-то сроки, даже самая мотивированная команда необратимо превращается в болото. Что вы, к сожалению, вероятно, нередко видите вокруг :)
Автор говорит совсем другое — сроки должны оценивать не специалисты, которые своими руками будут делать работу, а какой-то «менеджер» на белом коне, который, даже будучи в прошлом техническим специалистом, конкретных деталей реализации и многотонных подводных камней [уже] не знает.
И главная претензия к автору в том, что он как руководитель целого, по сути, направления, хочет полностью снять ответственность за сроки поставки с команды, лишив ее, пожалуй, самого главного мотивирующего фактора — commitment'а, личной ответственности и участия в жизни продукта.
Но автора работает в продуктовой разработке, где единственная цель определения временных затрат на задачу — оценить сроки выпуска очередной функциональности. Речь всегда идет об управлении сроками.
Поэтому противопоставление оценки сроков и оценки трудозатрат в часах — это неловкая манипуляция со стороны автора.
Когда в нормальной команде от разработчика (тестировщика) требуют оценки сроков выполнения задачи, от него ждут двух вещей:
1. Тщательного осознания задачи, ее декомпозиции при необходимости и описания будущего решения (плана тестирования) в тикете. Такой детальный разбор задачи на этапе планирования делается не индивидуально, а в команде. Он позволяет не делать фигни и заодно получить реалистичную оценку сроков выполнения (которая фиксируется в том же тикете).
2. Взятия на себя ответственности за заявленные сроки. Когда задача уже разобрана и решение понятно описано, команда и отдельный разработчик с открытыми глазами берет на себя ответственность за сроки. Это порождает совсем другое отношение к работе, чем спускаемые сверху непонятные, а иногда и безумные сроки от «менеджеров».
Потом из таких качественно предобработанных задач легко собираются управляемые итерации скрама.
Именно такие граждане сначала не требуют от разработчиков оценки задач, перевешивают ее на менеджеров, у которых должны быть совсем другие компетенции, а потом жалуются, что у них «скрам не работает».
Пишу как человек, полтора года руливший невероятно бодрой командой разработки из бывших сотрудников Контура, которая с этим подходом запилила качественный продукт и всегда соблюдала сроки поставки. Не сдержался :)
Почему-то мне кажется, что подавляющее большинство из ваших тысяч пользователей жмется покупать дополнительные возможности, а потому пользуется весьма бедной функциональностью. Потому что SMB никогда не купит для своего удобства то, что можно не покупать.
И таки да, TLS и SRTS у Манго включить нельзя. Пароль для подключения к учетке стыдливо прикрывается жиденьким MD5 и хэш гоняется в открытом виде. Голосовой трафик может слушать любой желающий.
Включить шифрование нельзя даже за деньги.
Сейчас я плачу 740 р./мес. за лицензию на вирутальную АТС (то есть, считая без номеров и звонков).
Если я включу у вас такие базовые вещи как черный список, запись разговоров с хранением в пределах 5ГБ, минимальные конференции, мониторинг и API, то я буду платить примерно 3 500 р./мес. за ваш супер-функциональный облачный софт.
Если остаться на минимальном тарифе и развернуть на облачной виртуалке за 300 р./мес. абсолютно бесплатный Asterisk, то даже если отдать за его настройку 15к, замена вашей нарезки функций окупится за полгода.
И никаких ограничений по количеству пользователей, записи звонков, конференциям, схемам переадресации и возможностям интеграции. И это при использовании вашей же телефонии.
Такое поведение строки поиска просто убивает, и явно ведь кто-то специально зачем-то это сделал. Расскажите хоть, зачем?