Казалось бы истина в заголовке, но я слишком часто встречал менеджеров(Project Manager/Product Owner) которые хотели схитрить и обойти это правило. Они приходят к команде разработки и говорят каждый на свой лад.
Ребят, надо быстро напилить фичу, сделайте ее как-нибудь, презентуем, посмотрим понравится ли клиенту и тогда уже переделаем нормально
Лёха, я знаю про то, что у нас нестабильно работает старый код и надо его переделать, но сейчас надо клиенту фичи показать, выбить деньги и тогда уже согласуем переделку неработающего функционала
Баги которые сейчас вылезают просто быстрыми фиксами закрой, а переделаем потом
Выше сказанное можно свести к одному простому: сделай быстро как нибудь, потом сделаем нормально.
От таких фраз происходит следующее:
Автотесты попадают под нож первыми, их не пишут или пишут для галочки
Ручное тестирование тоже проходит в облегченном варианте
Техдолг растет
Также хочу подсветить несколько моментов:
"Потом" может не наступить
Даже когда светлое будущее наступит, на переделку уйдет в 2-3 раза больше времени чем если бы мы сразу все сделали нормально
Также стоит учесть все то время которое потрачено на баги из-за корявых решений, на которые мы согласились
Предвещая неверное решение интуитивно, ты, как представитель команды разработки, об этом сообщаешь менеджеру, просишь дать времени сделать все правильно потому-что так выйдет дешевле клиенту, команде не придется страдать отлавливая баги и мы не рискуем парализовать проект или его часть техническим долгом. И каждый раз было так, что менеджеры кивали и делали по своему. На следующем планировании спринта нам приходит реализация новых фичей в быстром варианте, а про техдолг мы просто опять забыли.
Что дальше было?
На одну большую фичу пришли пользователи, нагрузки и нам пришлось потратить несколько месяцев на баги и переделку. Техдолг так и не рассосался до конца, это так и осталась страшная фича, в которую зайдет только смелый.
Другой проект оказалось практически невозможно развивать спустя несколько месяцев работы и его просто закрыли. Как итог - менеджер сменился.
Еще один проект, техдолг которого упорно не замечали, до того момента пока мы несколько спринтов подряд не начали заниматься только багами, то есть фактически он оказался парализован. Когда к тебе по 3-4 раза в день прибегает менеджер с каким-то срочным багом на проде, это просто дорога в могилу. Менеджер, кстати, и здесь сменился на нового.
А что произошло?
Я вот думаю, что были потрачены деньги на то, чтобы нанять и принять в команду новых умных программистов, платить им деньги за работу, тратить время на общение, но в итоге их часто не слушают, когда они говорят о том, что нужно переделать важный функционал. Может стоит нанимать умных людей и слушать их? Или это остатки советского мышления, что нам нужны “ученые” которые будут молча работать? Типа “результат их работы нам нужен, а их мнение - нет.”
У меня есть догадки, в чем была лично моя ошибка. Может я не умею верно доносить мысли до людей, может просто стоило более тщательно выбирать команду и проект для работы. Думаю стоит отдавать внимание чутью и настоять на своём, постараться донести мысль до менеджера и напомнить ещё раз то, с чего мы начали:
“Нормально делай - нормально будет. “
Комментарии (69)
lebedec
26.06.2022 08:49+9Может я не умею верно доносить мысли до людей, может просто стоило более тщательно выбирать команду и проект для работы. Думаю стоит отдавать внимание чутью и настоять на своём, постараться донести мысль до менеджера
Что если один из тиммейтов предложит вам быстренько влить откровенно нерабочий код в мастер? Вы сразу согласитесь на его уговоры, или аргументировано откажете и попросите внести правки?
А если в ваш код начнут коммитить ребята из соседних команд: QA, DevOps, системные администраторы? Вы согласитесь или будете разбираться с нарушителями границ вашей зоны ответственности? К менджерам в вопросах планирования работы надо относится точно так же.
К сожалению, многие думают, что менеджер представляет “власть”, имеет какой-то неоспоримый авторитет и покровительство над вами. Это не так. Менеджер — сотрудник, наравне с вами, решающий вопросы организации рабочего процесса. Даже ваш руководитель проекта, технический директор и операционный директор — не более чем сотрудники, которые решают организационные задачи, только с другим масштабом.
Чувствуйте себя уверено в обсуждении и постановке адекватных сроков для разработки качественных решений. Если такая позиция будет вызывать проблемы и конфликты с администраций компании — зачем оно вам надо, в отрасли полно других компаний, в которых такой подход точно оценят.
antonblockchain
27.06.2022 03:26-1если наравне то это не менеджер.
а мимопроходящий прохожий.
ваш менеджер это тот кто может вас уволить.
а остальные не ваши менеджеры — отсылайте их к своему менеджеру и для вас все станет проще.
fo_otman
26.06.2022 10:17+6Не впадайте в крайности. На всех нормальных проектах что-то делается сейчас, что-то оставляется на потом. Потом возвращаемся и рефакторим. Нет, проект не умирает. Нет, никто его осознанно не гробит. Нужно понимать, что есть 2 стороны - заказчик и исполнитель. Заказчику постоянно торопит, исполнитель постоянно затягивает сроки. На все есть свои причины, и они объективны. Ценность статьи мне не очень понятна, но видно, что у автора "подгорело", он написал ее на эмоциях. Можно также и другую точку зрения выслушать, но ведь заказчики не сидят на Хабре.
fransua
26.06.2022 10:30+1Если хотят сделать фичу быстро и показать клиенту - это норм, так бизнес зарабатывает деньги. Для этой фичи можно сделать отдельную ветку, накостылять там и показать клиенту. Нравится - делаем хорошо по накатанной и мерджим в мастер. Не понравилось - дропаем ветку.
А вот накостылять и замерджить в мастер - тут уже зона ответственности разраба, он и виноват. И его ответственность объяснять менеджеру, что в мастере нет этой фичи, ее нужно еще разработать правильно.
torbasow
26.06.2022 17:25+1накостылять там и показать клиенту. Нравится — делаем хорошо
Когда? Нравится — это значит будут пожелания новых фич. Ведь старые уже реализованы, вот же они!
Didimus
26.06.2022 19:08+1Хороший плиточник приклеит ровно одну плитку, после чего спросит, хозяин, устроит такой колор? Это надо использовать аналогии про строительство. В таком случае есть смысл продать заказчику MVP, а потом его масштабирование. И все довольны
AVX
26.06.2022 14:23+1Нужно чтобы после выкатки готовой версии заказчику давалось определённое время (где как называют - например, опытная эксплуатация), и если находятся баги, недоработки, или просто нерабочий функционал (который был заявлен в ТЗ) - чтобы компания разработчиков компенсировала деньгами потраченное фактически на QA время заказчика. Вот тогда и будут считать не фичи, а качество продукта, ибо это чревато потерей денег. Тогда и начнут более тщательно тестировать у себя, это будет экономнее и для имиджа полезнее.
У нас вот сейчас так - внедряют проект, и каждый день кучи недоработок и багов, и просто неработоспособные функции всплывают. И вместо того, чтобы проверить в нормальной работе, приходится описывать что не работает, где, при каких условиях, и т.д., переписываться с разработчиками и интеграторами (тут вообще странно, зачем тогда интеграторы? если на почти любой вопрос они переадресуют разработчикам, или говорят "это делают разработчики"). И это при фактически написанной "на отъ*ись" части документации (к слову, для нас важнейшей части, такой как "руководство администратора" и т.д.). Не буду называть компании, они себя узнают.
qw1
26.06.2022 23:35Компания-разработчик заложит среднюю цену штрафов в прайс (а как иначе, не разориться же им). А заказчик скажет «нет, спасибо, услугу страхования я покупать не хочу».
torbasow
26.06.2022 17:18+3«Потом» может не наступить
Что значит «может»? Разве бывает такое, что оно наступает?
Racheengel
26.06.2022 18:00+1У любого продукта есть свой жизненный цикл. Когда нибудь техдолг вырастет так, что проще будет "переписать заново", и в этом нет ничего плохого, это естественный процесс, как жизнь и смерть. Хороший менеджер должен понять приход этого момента и диверсифицировать развитие проекта - поддерживать то, что продано, по необходимости расширять то, что есть и ещё можно продавать, и параллельно начать разработку следующей версии, возможно на другой, более современной технологии. Да, это стоит денег и времени, но тесты и рефакторинг тоже не бесплатны.
Примеров много - Google Mail, Facebook, Skype vs Teams, MS Office, Visual Studio... все они прошли момент "перепись заново".
XaBoK
26.06.2022 18:54Часто нанимают специалистов для того, чтоб они отвечали хотелкам топ менеджмента. Работает это по принципу прослойки. Есть большой босс, который хочет "фичу". Есть некомпетентные менеджеры, которые либо не могу понять проблему в требованиях босса (технический кретинизм), либо боятся и не могут объяснить боссу проблему (управленческий кретинизм). Выход такие менеджеры видят в одном - нанять "звезду". Причем на роль звезды подходит не тот, кто действительно может решить проблему, а тот, кто согласиться это сделать быстро. Для прослойки - это идеальный вариант. Либо разработчик сделает то, что говорят и всё равно как, либо он виноват. А если сделал, а потом развалилось - опять таки виноват исполнитель.
muxa_ru
26.06.2022 19:05+1А вот как это выглядит с той стороны экрана, с которой находится пользователь - https://habr.com/ru/post/671872/ .
xeeaax
26.06.2022 20:18+1А что если...
В продукт надо запиливать фичи из которых только 15-20% идут потом в рост.
Можно находить компромиссы с PO, чтобы запиливать MVP фичи "по-быстрому", но так чтобы потом их рефактор "в 2-3 раза дороже" был управляемым? Например, договориться, что фича реализуется изолированно и не выпускается из тестовой группы на основную массу, пока не переписана качественно.
?
antonblockchain
27.06.2022 03:33+2А если в MVP будет дырка в безопасности что тогда?
Или он просто поставит раком нагруженную базу.
И встанет весь проект.
А как отдельная фича на пустой базе с 10 тестовыми пользователями работает ок.
ТО что теоретbчески должно встретится с реальными живыми данными и реальными пользователями уже не должно быть MVP.
WraithOW
27.06.2022 10:24А если в MVP будет дырка в безопасности что тогда?
То же, что и при дырке в обычной фиче.Или он просто поставит раком нагруженную базу.
Нагрузочное тестирование? Динамическая конфигурация, которая позволяет отключать фичи? Staged rollout? Не, не слышали.antonblockchain
27.06.2022 21:03+2Все это уже далеко заходит за MVP.
И похоже на стандартную разработку.WraithOW
28.06.2022 01:24+1Это называется «нормальные процессы в компании». И на рельсах этих нормальных процессов можно вполне гонять a/b тесты поверх mvp фич, которые суть изолированные модули, слепленные из говна, палок, копипасты и хардкода.
А если у вас процессов нет, то вы и при «стандартной разработке» будете визжать як порося, стоит лишь кому-то нечаянно задудосить бэк или проворонить xss.qw1
28.06.2022 09:45Так «процессы» и есть стандартная разработка. Сделать всё «по процессам» — это не забыть тесты, авторизацию, валидацию и т.д. и т.п.
Часть времени потратить на инфраструктуру, обработку ошибок, граничных случаев.WraithOW
28.06.2022 09:49+1Если «слепленные из говна, палок, копипасты и хардкода» для вас — «стандартная разработка», то мне добавить нечего.
XeaX
28.06.2022 10:53За редкими исключениями - очень плохо, на мой взгляд, если кто-то организовал продукт так, что работа над обычными фичами постоянно требует значимых ресурсов для анализа на дыры в безопасности.
Не надо писать даже в MVP-фиче то, что поставит раком нагруженную базу при согласованных ограничениях развертывания MVP. Часто можно дешевле сделать фичу, которая "не ставит раком базу", если заранее известно, что с ней будет работать, скажем, не более 5% от общего числа юзеров и на интервале, скажем, не более 6 месяцев.
Уверены, что знаете что такое MVP, когда пишете, что он не должен встречаться с реальными пользователями и живыми данными?
iReedar
27.06.2022 10:15Может менеджер вообще не должен приходить к "команде разработки" с какими-то идеями-пожеланиями? Тимлид/продактоунер должен быть каналом входа заданий и если они делают свою работу нормально, то донесут до менеджера и отстоят в процессе обсуждения с ним порядок исполнения задач.
Возможно не совсем в тему, но половина видео-туторов на русском по новым фичам в разработке на Youtube начинается со слов "Как-то прибежал ко мне менеджер и попросил сделать xxxxxxx, и сейчас я покажу вам как это сделать быстро и хорошо с помощью yyyyyy" Чудно это как-то )
bayanist68
27.06.2022 10:16Какая невероятно субъективная статья. Разработчики хорошие, и всегда говорят как лучше. Менеджер делает как хуже, потому что он злой и вообще саботажник.
Так не бывает, все намного сложней. Менеджер принимает решение исходя из десятков факторов, и качество кода - только один из них (хоть и важный, бесспорно). Есть еще куча вещей, которых разработчик может и не видеть. Если это заказная разработка, то без выкатки в прод "сырого" релиза следующего дня работы на проекте может и не быть. Или не будет поступления от этого заказчика и нечем платить зарплату тому же разработчику. То есть, часто в реалиях существующих ограничений, менеджер выбирает не между плохим и хорошим, а между плохим и очень плохим.
DonVietnam
27.06.2022 10:16-1Или это остатки советского мышления, что нам нужны “ученые” которые будут молча работать? Типа “результат их работы нам нужен, а их мнение - нет.”
Ох уж это советское мышление, когда на мнение людей плевать, а важен только результат любой ценной. Откуда в головах берётся этот антисоветский бред?
taras-m0
27.06.2022 10:21Основная задача менеджера это узнать у клиента чего он хочет и объяснить программистам в задачах. ТОЧКА.
Покажите мне менеджера, который знает весь функционал продукта.
dididididi
27.06.2022 15:09Нет, основный функционал найти компромисс между хотелками клиента и техническими возможностями. Сделать проект адекватным.
Пример: приходите вы в тюнинговое ателье и говорите удлините мне машину на 2 см, а то коленки упираются, то нормальный менеджер просто отодвинет сиденье. А не станет писать задание на удлинение тачки.
А в програмировании как раз так, начинаем костылями удлинять тачку.
First_Light
27.06.2022 13:10+1Когда я был молодым и зелёным РМом, меня наняла одна маленькая, но гордая компания. Она ОЧЕНЬ хотела громко заявить о себе и выкатить к определённой дате новый продукт, который пилила почти 2,5 года. На проекте была дикая текучка манагеров и разработчиков, но меня это почему-то тогда не смутило - я был молод, горяч,
хорош собойи полон энергии. Я был готов на плечах вынести проект, тем более и платить компания была готова весьма недурно.
Нееет, я не гонял сотрудников розгами и не стоял у них за спиной 8 часов. Я пошёл тыкать палочкой в СЕО, СТО и бэклог. И за два месяца их тормошения, полного разбора бэклога, нормального человеческого общения с разработчиками я понял, что проект если и успеет выйти к нужному сроку, то он ляжет уже через сутки. И ВНЕЗАПНО это знают абсолютно все разработчики на проекте, но молчат. А молчат потому, что коммерческий директор - неадекват на 146%, который и слушать не хочет ничего. Умри, но выдай к сроку продукт!
Пошёл разговаривать. Начал издалека, мягонько подводя к "Надо слушать разработчиков и исправить там, куда они покажут". На выходе же я получил истерику главы коммерческого департамента и коммдира, который плевался пеной и орал что-то бредовое.
Написал заявление уже через 2 недели и по сей день не жалею. А та самая компания сдала проект только через 4 месяца.
Мораль проста. Не всегда менеджер делает тупые вещи. Как ни грустно это признавать, но порой они - всего лишь ретрансляторы воли вышестоящего начальства, которое хочет чужими руками творить херню, а самих менеджеров в итоге увольнять / доводить до увольнения за то, что их идея провалилась.
Sadovikow
27.06.2022 17:23Не всегда бывает так, что фичу есть возможность пилить до идеального состояния, придерживаясь всем принципам, и не увеличивая тех. долг. Нужно снять розовые очки :)
Мне кажется тут просто необходимо учиться правильно балансировать между идеальной реализацией и увеличением технического долга. А так же регулярно заниматься отладкой и закрытием тех. долга., и будет счастье.
pyrk2142
Статья хороша, но, имхо, очень наивна. Основная проблема очень простая:
Менеджер не тупой, он осознанно гробит проект, ему это выгодно!
Разработчики очень часто считают, что менеджеры - это какие-то тупые создания, которым ничего не объяснить, надо рассказывать, что такое техдолг, почему это важно. Проблема в том, что нет почти ни одного менеджера, который это не понимает или не знает. Те, кто это не понимает, обычно настолько тупы, что не могут найти даже дорогу до офиса, их в расчет можно не брать.
Менеджеру в среднем не важно, что будет с проектом после его ухода, ему важно бабло сейчас. Заставил пилить фичу, но гробишь проект в будущем - молодец, держи ништяки. Заставил кодеров работать сверхурочно и пилить фичи - молодец, держи ништяк. Проект вышел на какую-то очередную формальную стадию - держи ништяк. Довел проект до такого состояния, что он умрет через полгода, но вовремя спрыгнул с галеры, найдя новую - крут, новая порция ништяков в пути. Нашел проект, который можно гробить годами - вообще красавчик. Угробил проект, но не нашел новую работу - вот тут не повезло, упс.
Пока менеджера не ставят в такие условия, что с проекта спрыгнуть он не сможет, уволиться тоже, а за результат он отвечает головой (или хотя бы всем имуществом), он будет его гробить, если это выгодно. И это логично просто потому, что человек пришел зарабатывать деньги, чтобы это делать нужно показывать результаты, а в большинстве случаев фичи выглядят ярче, чем минимум багов и технического долга. Иногда хватает времени и на то, и на то, иногда менеджер не успел спрыгнуть, поэтому команда может месяца два чинить все, менеджера выкинут.
С этим приходится жить, потому что это логичное поведение людей, эффективность которых оценивается именно так. Если проект настолько нравится, что хочется его защищать, то надо сначала принять для себя то, что менеджеру его судьба почти не важна. Да, есть исключения, есть честные менеджеры, есть идейные специалисты, но шанс их встретить не очень велик.
WTopchiev
Похожая ситуация про менеджеров-саботажников была описана вот здесь:
https://habr.com/ru/post/668404/
TimsTims
Да-да, менеджеры во всём виноваты. Разработчики думают о коде, но никто не думает о бизнесе. Давайте я расскажу, что было бы, если сразу делали по уму:
1) Разработка заняла бы на месяц больше времени.
2) Менеджер через месяц подходит к клиенту, тот говорит, что-то вы долго делаете, что фича ему уже не нужна, что им Васька- сын соседки Маши сделал на коленке, и всё работает «как часы» (конечно не как часы, но никто же не знает).
3) В итоге бизнес потратил месяц неоплачиваемой разработки на никому не нужную фичу.
4) Зато код красивый, и его легко поддерживать, да.
В идеале должныпо моему мнению, самый выгодный для бизнеса вариант такой:1) Узнаем бизнес-требования, в чем ценность, проникаемся идеей — что в ней самое важное.
2) Делаем mvp на коленке. Тратим не больше 1-2 дней.
3) Если фича взлетает — либо рефакторим, либо выкидываем найух код и пишем заново сразу красиво.
4) Если фича не взлетает — жмём плечаем, мы хотя бы пытались. Выкидываем код, не жалко.
antonblockchain
Новые Программисты регулярно предлагают выкинуть код.
И рассказывают про тех.долг и прочее.
Это понятно — разбираться в чужом коде это время которое НЕ ПОДНИМАЕТ твою ценность на рынке труда.
За это время можно запилить что-то новое, с фичами — но уже свое.
Эта работа поднимает ценность для следующего работодателя.
Так и работаем, каждый ищет свою ценность.
Программист желает написать свое, и оставить это следующему разработчику.
А менеджер сделать по быстрому и оставить тех. долг следующему менеджеру.
GooG2e
Хз конечно, но разве навыки работы с чужим кодом не поднимает твою стоимость в глазах работодателя, да и вообще готовность с ним работать. На мой взгляд накатать свой какой-то (ещё неизвестно какого качества) код сможет каждый, а вот разобраться в чужом, понять что он делает, понять почему он так делает и исправить в соответствии с новыми реалиями - вот это приличная ценность.
yerbabuena
Работодатель, даже может где-то на дне своих фантазий может и желал бы видеть такого работника, который вьехал бы и ментально подружился с имеющимся наследием без желания поработать по наследию сперва "Градом" с "Гиацинтами", а потом только начать строить свое с нуля. Но вслух и на публику скорее напишут "мы молодая команда, работаем безо всякого легаси, айда к нам", чем будут звать старого брюзгу, который видел этих "молодых команд" больше, чем блох на собаке и которому глубо "по и на" на проявляемый кем-то энтузиазм, но который при этом также ровно и спокойно начнет пилить фичи и править баги с ровным и прохладным отношением к очередному поделию йуных архитекторов и их манагеров.
SadOcean
Это фундаментальная проблема разработки ПО
Писать код легче, чем читать.
Отсюда, кстати, следует необходимость делать такую архитектуру, которая легко поддерживает расширение
antonblockchain
Не просто легче.
Но и ВЫГОДНЕЕ.
Выгодно этому\следующему работодателю сказать я пришел и все вам сделал до меня был мрак и ужас.
НА НОВЕЙШЕМ СУПЕРИНСТРУМЕНТЕ-БИБЛИОТЕКЕ,
Выгодно по ЗП.
А говорить я пришел и костылял ваш говнокод чтобы он не упал, и после меня там еще больше костылей.
В Вашем Delphi коде пополам с perl
Не выгодно.
randomsimplenumber
Жил-был успешный проект, развивался себе без особого техдолга. А потом пришёл менеджер и угробил. Конец сказки.
Мораль: если клиент платит только за новые фичи - к этому все и придет.
goodnickoff
А за что ещё он должен платить? За ваши косяки?
me21
За время, потраченное на багфиксы, тоже должен платить. Это часть процесса разработки.
goodnickoff
Вы платите за косяки строителей, когда нанимаете их строить дом или делать ремонт? Или может вы платите за косяки автомеханика?
muxa_ru
И за косяки и за то бухло, под которое они рассказывают коллегам о том, какое говно они вам сделали за конский прайс.
me21
Ну практика показывает, что в разработке ПО дела почему-то обстоят по-иному. Мои клиенты время, потраченное на багфиксы - оплачивают. Они об этом предупреждаются на старте и с этим согласны.
Наверное, потому что в разработке избежать багов намного сложнее, чем в строительстве или ремонте автомобиля.
yerbabuena
Но на порядок ипроще чем в той же стоматологии. Тем не менее, есть пусть и мелкий, но ненулевой объем прецедентов взыскивания расходов с дантистов за их косяки.
Kolonist
Вы с другим комментатором сравниваете несравнимые виды деятельности. Если в медицине ошибка - это нечто экстраординарное и недопустимое, то в разработке ПО - это рутинная и неизбежная часть процесса.
yerbabuena
... то почему же тогда одних только смертей от медицинских ошибок в тех же Штатах раз в 5 больше, чем смертей в ДТП (http://www.infowars.com/225000-american-patients-die-in-doctors-hands-silence-of-the-lambs/) ? Ну и рассказывать про "экстраординарность медицинских ошибок" не стоит человеку, который вырос в семье медиков, из которых 2 было хирургами и с дества наслышан про такое, чего хватило бы лет на 5 каждому из участников рассказов, если бы пациенты были чуть более в теме и чуть ближе к прокурорскому надзору :)
qw1
За качество надо платить. Так сложился консенсус между продавцами и покупателями на рынке. Если спросить у типичного заказчика ПО «вам побыстрее, подешевле, или без багов?», он выберет первые два, а баги уж как-нибудь потом починят.
Kolonist
Если Вы хотите сказать, что даже в медицине ошибка - это часть процесса работы врача, то какие тогда претензии к программистам?
Kolonist
А Вы заставляете строителей укладывать ламинат, хотя стяжка еще не высохла? Или клеить обои на сырую штукатурку? А автомехаников не просите по-быстрому поставить двигатель на тойоте от камаза, чтобы посмотреть, не будет ли машина быстрее ехать, а если что - потом отменить?
goodnickoff
Вас клиенты просят писать некачественный код или принимать заведомо неверные архитектурные решения?
SadOcean
Дефакто да
Потому что могут, потому что будет работать
ijustwanttobeacool
Платим. Они свои косяки в рамках «гарантии» исправляют. Там не роботы работают, а такие же люди, у которых горят сроки — отваливающиеся фасады в новеньких ЖК и незакрученные колёса после шиномонтажа сплошь и рядом
Вы можете сказать «гарантийный ремонт же за счёт исполнителя делается», но он уже включён в стоимость работ, как и в цену ПО включены багфиксы этого ПО
suslovas
Некорректное сравнение. К сожалению написание нового кода - это скорее исследовательская работа, а не формализованный процесс по инструкции.
Так что тут скорее можно спросить, оплачивается ли ученным отрицательный результат исследования и да - оплачивается.
lebedec
Вы так демонизируете менеджеров, как будто это какие-то особые люди.
Вы ведь не считаете, что разработчики святые? Среди них есть такие же ребята, которые осознано гробят проект ради собственной выгоды. Они затаскивают новые технологии и подходы в разработку только чтобы удовлетворить свой технический интерес или натренировать навыки необходимые для перехода в другую компанию, а что будет с проектом потом им не интересно.
Но в целом, я с вами не спорю. Качество работы любого сотрудника — это вопрос его мотивации.
Kolonist
Наемным сотрудникам в принципе не интересно, что будет с проектом после их ухода, будь то менеджеры, разработчики, дизайнеры или кто-либо еще.
Единственные, кому интересен проект, и кто хочет максимально обеспечить и продлить его жизнь - это владельцы бизнеса.
А потому, одна из главных задач владельцев бизнеса - обеспечить такую мотивацию наемным сотрудникам, чтобы им и не хотелось, и было не выгодно гробить проект.
Как это сделать - вопрос отдельного исследования. Тут и опционы (если у меня акции компании, то мне выгодно, чтобы она росла и дорожала даже после моего ухода), и регулярно повышаемая зарплата выше рынка вкупе с другими бонусами (чтобы сотрудники задерживались в компании на максимально возможный срок), и еще куча всяких методов от умных исследователей, бизнесменов и психологов.
yerbabuena
Таки да. Это люди, желающие процветать за счет работы на них других людей (пресловутое "гномики еще накопают" ) и принуждения к этой работе любыми средствами, включая недоговаривание и откровенное вранье (приватизация прибылей и национализация убытков). Т.е. это люди с таким вот моральным вывертом.
andreyverbin
Почему бы вам не попробовать тогда работать без менеджеров?
torbasow
Ах! Боже мой! Он карбонарий! Опасный человек!
yerbabuena
Они - неизбежное зло. Но в каждом менеджере/начальнике/руководителе сидит маленький А.Б. Чубайс, и помнить про это стоит всегда, чтобы не было неприятных разочарований типа описанных в статье.
yerbabuena
И в чем я не прав, минусующие?
Manguss
"Стоит не забывать что в каждом работнике сидит, ленивое лживое существо которое отчитается что сделало, а либо не сделает вообще или абы как."(продолжая логику @yerbabuena)
Ужас, ужас, оказывается людская сущность везде может показать свои негативные стороны и на уровне работника, менеджера, и даже собственник бизнеса может быть глуп некомпетентен и уничтожить свой бизнес.
yerbabuena
Да, но начальник, по роду своей деятельности, с одной стороны, находится на пути к доходам без стеклянного потолка, а с другой стороны, его ошибки или вредительство гораздо масштабнее по последствиям, нежели любые действия линейного работника (человек без полномочий украдет гайку на железной дороге, человек с полномочиями украдет всю железную дорогу). При этом, чем выше он идет по административной лестнице, тем меньший у него уровень ответственности, особенно перед подчиненными, как минимум, последние лет 70. И именно вот такой микс их и выделяет из остальных людей.
samizdam
Отматал на 70 лет, сталинизмом повеяло.
Мне как-то ближе, что можно без террора и массовых убийств эффективно взаимодействовать внутри вида.
yerbabuena
И как же, к примеру, надо было "эффективно взаимодействовать " с теми же СЕО большого автомобильного трио США, которые в 2008 помчались в Конгресс выбивать деньги на спасение компаний, которые они довели до банкротств? Так эти твари не только неприсели за свои художества, так еще и премии получили за свои "подвиги". Я не говорю уже про кадры помельче, которые доводят компанию до банкротства, работников - до выставления на улицу, а сами с золотым парашютом перелетают гробить следующую. Вот как с такими предлагаете "взаимодействовать"?
fougasse
Это очень зациклено на «галерах» и возможности «прыгать» с одной на другую с рынком аутсорса.
На продуктовом и/или небольшом рынке так не попрыгаешь, да и мест для «прыжков» поменьше, особенно в некоторых областях.
Да, можно посрубать «ништяков» некоторое время, а потом уйти в лыжные/серфинг инструктора. Тоже вариант, и даже реальный.
TimsTims
Manguss
Я Менеджер и испытываю обратные трудности, я уговариваю разработку заняться техдолгом, готов согласовать им на это все ресурсы и время, постоянно уговариваю протестировать нормально. в итоге получаю тяп ляп и в продакшен. Постоянно не соблюдает сроки разработка при том что именно они оценивают на базе бизнес-требований и ТЗ от бизнеса сколько это займет времени и сами же регулярно не попадают в этот срок. Доказать полезность декомпозиции глубже чем Анализ-Написание ТЗ-Разработка-В продакшен. В общем как всегда не однозначно все. Здесь больше разработчиков потому правило хорошего тона поругать плохого HR и менеджер. а правда в каждом случае будет своя.
Ну и реально не тривиальная проблема поддержать необходимый баланс между красивым кодом и фичей полученной во время.
nikolas78
Потому что за проект отвечать должен один человек, а не перебрасывать ответственность с рарзрабов на менеджеров и обратно.
antonblockchain
Которому разработчики неправильно планируют его проект.
Разработчики дают оценку и не попадают в них.
А не соблюдает СРОКИ установленные с использованием этих оценок МЕНЕДЖЕР.
Он за это деньги получает и это целиком его вина.
Используй оценки правильно или уйди с проекта.
Во всем остальном мире планирование была работой менеджера.
А теперь вы скинули планирование часть ВАШЕЙ работы причем самую важную вниз-
«Постоянно не соблюдает сроки разработка при том что именно они оценивают на базе бизнес-требований и ТЗ от бизнеса сколько это займет времени и сами же регулярно не попадают в этот срок. Д»
Вам ее сделали плохо потому что это работа менеджера оценки и планирование.
А там внизу разработчики.
И другого настоящего менеджера который умеет оценивать сроки там внизу — СЮРПРИЗ — тоже нет.
И вы теперь глубоко расстроены, что вашу работу сделали за ВАС же плохо…
Интересно что скажут Инженеру прорабу по стройке если он попросит каменщика оценить объем работы?