Comments 13
Самое главное заблуждение этой статьи:
У менеджера больше свободного времени, чтобы заниматься этим. Сотрудники с опытом прекрасно знают проблемы и перспективы продукта, получше менеджеров, т.к. напрямую работают с ним. Просто у них обычно очень много своей работы, и фактически нет времени заниматься этими проблемами продукта.
у менеджера больше возможностей посмотреть на ситуацию под другим углом, т.к. рядовым сотрудникам не всегда хватает широты взгляда или информации, чтобы сравнивать своё детище с конкурентами, и они просто по инерции следуют за общественным мнением
У менеджера больше свободного времени, чтобы заниматься этим. Сотрудники с опытом прекрасно знают проблемы и перспективы продукта, получше менеджеров, т.к. напрямую работают с ним. Просто у них обычно очень много своей работы, и фактически нет времени заниматься этими проблемами продукта.
По поводу опытных сотрудников вы точно заметили. Особенно это проявляется, когда хотят «привнести свежую кровь» и назначают человека не разбирающегося ни в предметной области, ни в процессе разработки продуктов. Усугубляется это тем, что он и не хочет разбираться и всё знает лучше всех. Примерно, так и было с предыдущим продуктом…
Но по поводу заблуждения не соглашусь. Менеджер, который хочет добиться какого то положительного результата в работе над своим продуктом должен быть на передовой и как не построен процесс разработки, он всё равно должен стремиться к тому, чтобы получать больше объективной информации из разных источников, в том числе и от опытных разработчиков. «Неопытность» разработчика в этом вопросе гораздо менее критична для общего успеха дела, чем «неопытность» менеджера.
Но по поводу заблуждения не соглашусь. Менеджер, который хочет добиться какого то положительного результата в работе над своим продуктом должен быть на передовой и как не построен процесс разработки, он всё равно должен стремиться к тому, чтобы получать больше объективной информации из разных источников, в том числе и от опытных разработчиков. «Неопытность» разработчика в этом вопросе гораздо менее критична для общего успеха дела, чем «неопытность» менеджера.
Боюсь, что это скорее Ваше заблуждение, по поводу количества свободного времени у менеджера.
Если менеджер занимается делом, то у него ответственности и забот гораздо больше чем у любого разработчика, и неважно, насколько разработчик опытный. Кроме того, проблема, описанная в статье, находится в зоне ответственности менеджера. Именно потому, что у него, в отличие от разработчиков, есть доступ к информации и возможности влияния на ситуацию. Работа у него такая.
Если менеджер занимается делом, то у него ответственности и забот гораздо больше чем у любого разработчика, и неважно, насколько разработчик опытный. Кроме того, проблема, описанная в статье, находится в зоне ответственности менеджера. Именно потому, что у него, в отличие от разработчиков, есть доступ к информации и возможности влияния на ситуацию. Работа у него такая.
Знакомая ситуация, тут самый сложный период начинается когда маховик внедрения новых функций раскручивается настолько быстро что начинает хромать общее качество продукта. У девелоперов нет времени на рефакторинг, который время от времени необходим как воздух.
Но и у менеджеров тоже свои задачи, если не будут доставлять отчеты об успешном развитии продукта и нахваливать босса то его просто уволят.
Но и у менеджеров тоже свои задачи, если не будут доставлять отчеты об успешном развитии продукта и нахваливать босса то его просто уволят.
У девелоперов нет времени на рефакторинг, который время от времени необходим как воздухАбсолютная правда ваша, но к сожалению, не все упирается во время или не только во время — часто самая сложная проблема, это донести до руководства, что технический долг, который копили годами, скоро рухнет многотонным грузом на проект и погребет под собой все.
Иногда и менеджер ничего не решает и поставлен в рамки: ничего не делается, если ты не можешь это фактурировать (иначе продать).
Часто менеджер пытается запихнуть хотя бы часть насущного редизайна в какой-нибудь релиз, клиенты и/или руководство ругаются — почему он так дорог? — девелоперы же пытаются одновременно с кучей нового функционала как-то отрефакторить хотя бы что-то, в результате делая часто двойную/тройную работу. Саппорт растет. Тех-долг растет. Скорость разработки все падает и падает. Ошибки растут с каждым релизом.
Де факто, не выигрывает никто, ибо в который раз:
— девелопер: блин, была бы вот эта фича уже допилена, сейчас бы за 2 часа прикрутил, а так неделю возиться (а чтобы ее закончить, нужно вот_это, а чтоб вот_это допилить, нужно… заморозить разработку на несколько недель...)
— менеджер: как бы мне эту неделю «продать» (клиент готов раскошелиться только на 2 дня), если это выкинуть, то это отложим на завтра, если это, то вот эту фичу не сделать… черт, черт, черт…
— руководство: вы там офигели что-ли, ваш бюджет уже превышен в полтора раза? И когда уже релиз? И почему саппорт (клиент) не доволен? И кстати у нас что такой некачественный продукт, что столько саппорта?
— саппорт: сколько этот тикет может лежать в акцептед? уже полгода прошло, у меня по нескольку звонков в день, когда наконец уже поправите? И кстати сегодня 5 новых тикетов, вы уже видели?
И вот если в этот «отлаженый» механизм разработки добавить фактор внезапности (например, внезапно обнаружилась ошибка, которую допустили при обновлении на релиз 08.01, а сейчас на дворе 10.05, и нужно срочно писать огромаднейший repair-script), то скорее всего уже все, пришел пушной зверь, и «А я вам говорил» уже позно — как правило это «А пошли все...» и «Подпишите заявление ...».
В одной из компаний, где я проработал меньше года, на протяжении всего времени громко ругал существующий код. При этом тот легаси, который достался по наследству, в буквальном смысле тянул бизнес компании на дно. Нужно было что-то с этим делать. Объединились с другими ребятами, сформулировали проблемы и пошли к ген.диру. Доводы на него не подействовали, репутация продукта внутри команды стала еще хуже. Так как перспектив нормального развития продукта не было, а желание что-то изменить в лучшую сторону было, команда очень быстро распалась. Компания по сей день медленно, но верно теряет существующих клиентов.
> которые его делают в режиме 24/7
У вас программисты посменно работают или просто цепи крепкие?
У вас программисты посменно работают или просто цепи крепкие?
Имелось в виду 5 на 8. Спасибо, что внимательно читаете. Последнее время график максимально гибкий и предыдущие попытки руководства загнать разработчиков в ''график банка'' не к чему не привели… грызть кактус в условиях жёсткого графика то ещё удовольствие…
Если сотрудники ругают на чем свет стоит свой продукт при кадом удобном случае, у них нет мотивации продуктивно работать-это говорит о том что у таких сотрудников нет эффективного руководителя и лидера, который может взять ситуацию под контроль, мотивировать сотрудников, начать делать продукт качественным и удобным в использовании. К кому в этом случае обращатся прстому разрабочику? К менеджеру? Если менеджер признает эти факты, то он автоматически признает и оо что он не эффективный менеджер. А критику, тем более исходящую от подчиненных никто не любит.
Очень печально читать такие статьи: понимаешь, что ты не одинок в подобной ситуации, и по рынку таких проблем много. А ведь всегда кажется, что в других компаниях и трава зеленее, и вода мокрее, и девушки красивее.
Компании, в которых все лучше, зеленее, мокрее и красивее, тоже есть. В них удалось либо избежать описанной в статье ситуации (например, за счет того, что все изначально пользовались своим продуктом и продолжают его делать не просто «как для себя», а на самом деле для себя), либо справиться с ситуацией (чего топикстартер, я так понимаю, тоже достиг в рамках доступного ему маневра).
Sign up to leave a comment.
Мыши плакали, кололись, но продолжали грызть кактус