Comments 72
Статья хороша, но, имхо, очень наивна. Основная проблема очень простая:
Менеджер не тупой, он осознанно гробит проект, ему это выгодно!
Разработчики очень часто считают, что менеджеры - это какие-то тупые создания, которым ничего не объяснить, надо рассказывать, что такое техдолг, почему это важно. Проблема в том, что нет почти ни одного менеджера, который это не понимает или не знает. Те, кто это не понимает, обычно настолько тупы, что не могут найти даже дорогу до офиса, их в расчет можно не брать.
Менеджеру в среднем не важно, что будет с проектом после его ухода, ему важно бабло сейчас. Заставил пилить фичу, но гробишь проект в будущем - молодец, держи ништяки. Заставил кодеров работать сверхурочно и пилить фичи - молодец, держи ништяк. Проект вышел на какую-то очередную формальную стадию - держи ништяк. Довел проект до такого состояния, что он умрет через полгода, но вовремя спрыгнул с галеры, найдя новую - крут, новая порция ништяков в пути. Нашел проект, который можно гробить годами - вообще красавчик. Угробил проект, но не нашел новую работу - вот тут не повезло, упс.
Пока менеджера не ставят в такие условия, что с проекта спрыгнуть он не сможет, уволиться тоже, а за результат он отвечает головой (или хотя бы всем имуществом), он будет его гробить, если это выгодно. И это логично просто потому, что человек пришел зарабатывать деньги, чтобы это делать нужно показывать результаты, а в большинстве случаев фичи выглядят ярче, чем минимум багов и технического долга. Иногда хватает времени и на то, и на то, иногда менеджер не успел спрыгнуть, поэтому команда может месяца два чинить все, менеджера выкинут.
С этим приходится жить, потому что это логичное поведение людей, эффективность которых оценивается именно так. Если проект настолько нравится, что хочется его защищать, то надо сначала принять для себя то, что менеджеру его судьба почти не важна. Да, есть исключения, есть честные менеджеры, есть идейные специалисты, но шанс их встретить не очень велик.
Похожая ситуация про менеджеров-саботажников была описана вот здесь:
1) Разработка заняла бы на месяц больше времени.
2) Менеджер через месяц подходит к клиенту, тот говорит, что-то вы долго делаете, что фича ему уже не нужна, что им Васька- сын соседки Маши сделал на коленке, и всё работает «как часы» (конечно не как часы, но никто же не знает).
3) В итоге бизнес потратил месяц неоплачиваемой разработки на никому не нужную фичу.
4) Зато код красивый, и его легко поддерживать, да.
1) Узнаем бизнес-требования, в чем ценность, проникаемся идеей — что в ней самое важное.
2) Делаем mvp на коленке. Тратим не больше 1-2 дней.
3) Если фича взлетает — либо рефакторим, либо выкидываем найух код и пишем заново сразу красиво.
4) Если фича не взлетает — жмём плечаем, мы хотя бы пытались. Выкидываем код, не жалко.
И рассказывают про тех.долг и прочее.
Это понятно — разбираться в чужом коде это время которое НЕ ПОДНИМАЕТ твою ценность на рынке труда.
За это время можно запилить что-то новое, с фичами — но уже свое.
Эта работа поднимает ценность для следующего работодателя.
Так и работаем, каждый ищет свою ценность.
Программист желает написать свое, и оставить это следующему разработчику.
А менеджер сделать по быстрому и оставить тех. долг следующему менеджеру.
Хз конечно, но разве навыки работы с чужим кодом не поднимает твою стоимость в глазах работодателя, да и вообще готовность с ним работать. На мой взгляд накатать свой какой-то (ещё неизвестно какого качества) код сможет каждый, а вот разобраться в чужом, понять что он делает, понять почему он так делает и исправить в соответствии с новыми реалиями - вот это приличная ценность.
Хз конечно, но разве навыки работы с чужим кодом не поднимает твою стоимость в глазах работодателя, да и вообще готовность с ним работать.
Работодатель, даже может где-то на дне своих фантазий может и желал бы видеть такого работника, который вьехал бы и ментально подружился с имеющимся наследием без желания поработать по наследию сперва "Градом" с "Гиацинтами", а потом только начать строить свое с нуля. Но вслух и на публику скорее напишут "мы молодая команда, работаем безо всякого легаси, айда к нам", чем будут звать старого брюзгу, который видел этих "молодых команд" больше, чем блох на собаке и которому глубо "по и на" на проявляемый кем-то энтузиазм, но который при этом также ровно и спокойно начнет пилить фичи и править баги с ровным и прохладным отношением к очередному поделию йуных архитекторов и их манагеров.
Это фундаментальная проблема разработки ПО
Писать код легче, чем читать.
Отсюда, кстати, следует необходимость делать такую архитектуру, которая легко поддерживает расширение
Но и ВЫГОДНЕЕ.
Выгодно этому\следующему работодателю сказать я пришел и все вам сделал до меня был мрак и ужас.
НА НОВЕЙШЕМ СУПЕРИНСТРУМЕНТЕ-БИБЛИОТЕКЕ,
Выгодно по ЗП.
А говорить я пришел и костылял ваш говнокод чтобы он не упал, и после меня там еще больше костылей.
В Вашем Delphi коде пополам с perl
Не выгодно.
Жил-был успешный проект, развивался себе без особого техдолга. А потом пришёл менеджер и угробил. Конец сказки.
Мораль: если клиент платит только за новые фичи - к этому все и придет.
А за что ещё он должен платить? За ваши косяки?
За время, потраченное на багфиксы, тоже должен платить. Это часть процесса разработки.
Вы платите за косяки строителей, когда нанимаете их строить дом или делать ремонт? Или может вы платите за косяки автомеханика?
Вы платите за косяки строителей, когда нанимаете их строить дом или делать ремонт? Или может вы платите за косяки автомеханика?
И за косяки и за то бухло, под которое они рассказывают коллегам о том, какое говно они вам сделали за конский прайс.
Ну практика показывает, что в разработке ПО дела почему-то обстоят по-иному. Мои клиенты время, потраченное на багфиксы - оплачивают. Они об этом предупреждаются на старте и с этим согласны.
Наверное, потому что в разработке избежать багов намного сложнее, чем в строительстве или ремонте автомобиля.
Наверное, потому что в разработке избежать багов намного сложнее, чем в строительстве или ремонте автомобиля.
Но на порядок ипроще чем в той же стоматологии. Тем не менее, есть пусть и мелкий, но ненулевой объем прецедентов взыскивания расходов с дантистов за их косяки.
Вы с другим комментатором сравниваете несравнимые виды деятельности. Если в медицине ошибка - это нечто экстраординарное и недопустимое, то в разработке ПО - это рутинная и неизбежная часть процесса.
Если в медицине ошибка - это нечто экстраординарное и недопустимое,
... то почему же тогда одних только смертей от медицинских ошибок в тех же Штатах раз в 5 больше, чем смертей в ДТП (http://www.infowars.com/225000-american-patients-die-in-doctors-hands-silence-of-the-lambs/) ? Ну и рассказывать про "экстраординарность медицинских ошибок" не стоит человеку, который вырос в семье медиков, из которых 2 было хирургами и с дества наслышан про такое, чего хватило бы лет на 5 каждому из участников рассказов, если бы пациенты были чуть более в теме и чуть ближе к прокурорскому надзору :)
Если Вы хотите сказать, что даже в медицине ошибка - это часть процесса работы врача, то какие тогда претензии к программистам?
А Вы заставляете строителей укладывать ламинат, хотя стяжка еще не высохла? Или клеить обои на сырую штукатурку? А автомехаников не просите по-быстрому поставить двигатель на тойоте от камаза, чтобы посмотреть, не будет ли машина быстрее ехать, а если что - потом отменить?
Платим. Они свои косяки в рамках «гарантии» исправляют. Там не роботы работают, а такие же люди, у которых горят сроки — отваливающиеся фасады в новеньких ЖК и незакрученные колёса после шиномонтажа сплошь и рядом
Вы можете сказать «гарантийный ремонт же за счёт исполнителя делается», но он уже включён в стоимость работ, как и в цену ПО включены багфиксы этого ПО
Некорректное сравнение. К сожалению написание нового кода - это скорее исследовательская работа, а не формализованный процесс по инструкции.
Так что тут скорее можно спросить, оплачивается ли ученным отрицательный результат исследования и да - оплачивается.
Вы так демонизируете менеджеров, как будто это какие-то особые люди.
Вы ведь не считаете, что разработчики святые? Среди них есть такие же ребята, которые осознано гробят проект ради собственной выгоды. Они затаскивают новые технологии и подходы в разработку только чтобы удовлетворить свой технический интерес или натренировать навыки необходимые для перехода в другую компанию, а что будет с проектом потом им не интересно.
Но в целом, я с вами не спорю. Качество работы любого сотрудника — это вопрос его мотивации.
Наемным сотрудникам в принципе не интересно, что будет с проектом после их ухода, будь то менеджеры, разработчики, дизайнеры или кто-либо еще.
Единственные, кому интересен проект, и кто хочет максимально обеспечить и продлить его жизнь - это владельцы бизнеса.
А потому, одна из главных задач владельцев бизнеса - обеспечить такую мотивацию наемным сотрудникам, чтобы им и не хотелось, и было не выгодно гробить проект.
Как это сделать - вопрос отдельного исследования. Тут и опционы (если у меня акции компании, то мне выгодно, чтобы она росла и дорожала даже после моего ухода), и регулярно повышаемая зарплата выше рынка вкупе с другими бонусами (чтобы сотрудники задерживались в компании на максимально возможный срок), и еще куча всяких методов от умных исследователей, бизнесменов и психологов.
Вы так демонизируете менеджеров, как будто это какие-то особые люди.
Таки да. Это люди, желающие процветать за счет работы на них других людей (пресловутое "гномики еще накопают" ) и принуждения к этой работе любыми средствами, включая недоговаривание и откровенное вранье (приватизация прибылей и национализация убытков). Т.е. это люди с таким вот моральным вывертом.
Почему бы вам не попробовать тогда работать без менеджеров?
Они - неизбежное зло. Но в каждом менеджере/начальнике/руководителе сидит маленький А.Б. Чубайс, и помнить про это стоит всегда, чтобы не было неприятных разочарований типа описанных в статье.
И в чем я не прав, минусующие?
"Стоит не забывать что в каждом работнике сидит, ленивое лживое существо которое отчитается что сделало, а либо не сделает вообще или абы как."(продолжая логику @yerbabuena)
Ужас, ужас, оказывается людская сущность везде может показать свои негативные стороны и на уровне работника, менеджера, и даже собственник бизнеса может быть глуп некомпетентен и уничтожить свой бизнес.
Да, но начальник, по роду своей деятельности, с одной стороны, находится на пути к доходам без стеклянного потолка, а с другой стороны, его ошибки или вредительство гораздо масштабнее по последствиям, нежели любые действия линейного работника (человек без полномочий украдет гайку на железной дороге, человек с полномочиями украдет всю железную дорогу). При этом, чем выше он идет по административной лестнице, тем меньший у него уровень ответственности, особенно перед подчиненными, как минимум, последние лет 70. И именно вот такой микс их и выделяет из остальных людей.
Отматал на 70 лет, сталинизмом повеяло.
Мне как-то ближе, что можно без террора и массовых убийств эффективно взаимодействовать внутри вида.
И как же, к примеру, надо было "эффективно взаимодействовать " с теми же СЕО большого автомобильного трио США, которые в 2008 помчались в Конгресс выбивать деньги на спасение компаний, которые они довели до банкротств? Так эти твари не только неприсели за свои художества, так еще и премии получили за свои "подвиги". Я не говорю уже про кадры помельче, которые доводят компанию до банкротства, работников - до выставления на улицу, а сами с золотым парашютом перелетают гробить следующую. Вот как с такими предлагаете "взаимодействовать"?
Это очень зациклено на «галерах» и возможности «прыгать» с одной на другую с рынком аутсорса.
На продуктовом и/или небольшом рынке так не попрыгаешь, да и мест для «прыжков» поменьше, особенно в некоторых областях.
Да, можно посрубать «ништяков» некоторое время, а потом уйти в лыжные/серфинг инструктора. Тоже вариант, и даже реальный.
Менеджеру в среднем не важно, что будет с проектом после его ухода, ему важно бабло сейчас.Подставьте на это место «разработчик», и ничего не изменится, ваш текст останется правдивым.
Я Менеджер и испытываю обратные трудности, я уговариваю разработку заняться техдолгом, готов согласовать им на это все ресурсы и время, постоянно уговариваю протестировать нормально. в итоге получаю тяп ляп и в продакшен. Постоянно не соблюдает сроки разработка при том что именно они оценивают на базе бизнес-требований и ТЗ от бизнеса сколько это займет времени и сами же регулярно не попадают в этот срок. Доказать полезность декомпозиции глубже чем Анализ-Написание ТЗ-Разработка-В продакшен. В общем как всегда не однозначно все. Здесь больше разработчиков потому правило хорошего тона поругать плохого HR и менеджер. а правда в каждом случае будет своя.
Ну и реально не тривиальная проблема поддержать необходимый баланс между красивым кодом и фичей полученной во время.
Разработчики дают оценку и не попадают в них.
А не соблюдает СРОКИ установленные с использованием этих оценок МЕНЕДЖЕР.
Он за это деньги получает и это целиком его вина.
Используй оценки правильно или уйди с проекта.
Во всем остальном мире планирование была работой менеджера.
А теперь вы скинули планирование часть ВАШЕЙ работы причем самую важную вниз-
«Постоянно не соблюдает сроки разработка при том что именно они оценивают на базе бизнес-требований и ТЗ от бизнеса сколько это займет времени и сами же регулярно не попадают в этот срок. Д»
Вам ее сделали плохо потому что это работа менеджера оценки и планирование.
А там внизу разработчики.
И другого настоящего менеджера который умеет оценивать сроки там внизу — СЮРПРИЗ — тоже нет.
И вы теперь глубоко расстроены, что вашу работу сделали за ВАС же плохо…
Интересно что скажут Инженеру прорабу по стройке если он попросит каменщика оценить объем работы?
Спасибо
Может я не умею верно доносить мысли до людей, может просто стоило более тщательно выбирать команду и проект для работы. Думаю стоит отдавать внимание чутью и настоять на своём, постараться донести мысль до менеджера
Что если один из тиммейтов предложит вам быстренько влить откровенно нерабочий код в мастер? Вы сразу согласитесь на его уговоры, или аргументировано откажете и попросите внести правки?
А если в ваш код начнут коммитить ребята из соседних команд: QA, DevOps, системные администраторы? Вы согласитесь или будете разбираться с нарушителями границ вашей зоны ответственности? К менджерам в вопросах планирования работы надо относится точно так же.
К сожалению, многие думают, что менеджер представляет “власть”, имеет какой-то неоспоримый авторитет и покровительство над вами. Это не так. Менеджер — сотрудник, наравне с вами, решающий вопросы организации рабочего процесса. Даже ваш руководитель проекта, технический директор и операционный директор — не более чем сотрудники, которые решают организационные задачи, только с другим масштабом.
Чувствуйте себя уверено в обсуждении и постановке адекватных сроков для разработки качественных решений. Если такая позиция будет вызывать проблемы и конфликты с администраций компании — зачем оно вам надо, в отрасли полно других компаний, в которых такой подход точно оценят.
Не впадайте в крайности. На всех нормальных проектах что-то делается сейчас, что-то оставляется на потом. Потом возвращаемся и рефакторим. Нет, проект не умирает. Нет, никто его осознанно не гробит. Нужно понимать, что есть 2 стороны - заказчик и исполнитель. Заказчику постоянно торопит, исполнитель постоянно затягивает сроки. На все есть свои причины, и они объективны. Ценность статьи мне не очень понятна, но видно, что у автора "подгорело", он написал ее на эмоциях. Можно также и другую точку зрения выслушать, но ведь заказчики не сидят на Хабре.
Если хотят сделать фичу быстро и показать клиенту - это норм, так бизнес зарабатывает деньги. Для этой фичи можно сделать отдельную ветку, накостылять там и показать клиенту. Нравится - делаем хорошо по накатанной и мерджим в мастер. Не понравилось - дропаем ветку.
А вот накостылять и замерджить в мастер - тут уже зона ответственности разраба, он и виноват. И его ответственность объяснять менеджеру, что в мастере нет этой фичи, ее нужно еще разработать правильно.
накостылять там и показать клиенту. Нравится — делаем хорошо
Когда? Нравится — это значит будут пожелания новых фич. Ведь старые уже реализованы, вот же они!
Хороший плиточник приклеит ровно одну плитку, после чего спросит, хозяин, устроит такой колор? Это надо использовать аналогии про строительство. В таком случае есть смысл продать заказчику MVP, а потом его масштабирование. И все довольны
Нужно чтобы после выкатки готовой версии заказчику давалось определённое время (где как называют - например, опытная эксплуатация), и если находятся баги, недоработки, или просто нерабочий функционал (который был заявлен в ТЗ) - чтобы компания разработчиков компенсировала деньгами потраченное фактически на QA время заказчика. Вот тогда и будут считать не фичи, а качество продукта, ибо это чревато потерей денег. Тогда и начнут более тщательно тестировать у себя, это будет экономнее и для имиджа полезнее.
У нас вот сейчас так - внедряют проект, и каждый день кучи недоработок и багов, и просто неработоспособные функции всплывают. И вместо того, чтобы проверить в нормальной работе, приходится описывать что не работает, где, при каких условиях, и т.д., переписываться с разработчиками и интеграторами (тут вообще странно, зачем тогда интеграторы? если на почти любой вопрос они переадресуют разработчикам, или говорят "это делают разработчики"). И это при фактически написанной "на отъ*ись" части документации (к слову, для нас важнейшей части, такой как "руководство администратора" и т.д.). Не буду называть компании, они себя узнают.
«Потом» может не наступить
Что значит «может»? Разве бывает такое, что оно наступает?
У любого продукта есть свой жизненный цикл. Когда нибудь техдолг вырастет так, что проще будет "переписать заново", и в этом нет ничего плохого, это естественный процесс, как жизнь и смерть. Хороший менеджер должен понять приход этого момента и диверсифицировать развитие проекта - поддерживать то, что продано, по необходимости расширять то, что есть и ещё можно продавать, и параллельно начать разработку следующей версии, возможно на другой, более современной технологии. Да, это стоит денег и времени, но тесты и рефакторинг тоже не бесплатны.
Примеров много - Google Mail, Facebook, Skype vs Teams, MS Office, Visual Studio... все они прошли момент "перепись заново".
Часто нанимают специалистов для того, чтоб они отвечали хотелкам топ менеджмента. Работает это по принципу прослойки. Есть большой босс, который хочет "фичу". Есть некомпетентные менеджеры, которые либо не могу понять проблему в требованиях босса (технический кретинизм), либо боятся и не могут объяснить боссу проблему (управленческий кретинизм). Выход такие менеджеры видят в одном - нанять "звезду". Причем на роль звезды подходит не тот, кто действительно может решить проблему, а тот, кто согласиться это сделать быстро. Для прослойки - это идеальный вариант. Либо разработчик сделает то, что говорят и всё равно как, либо он виноват. А если сделал, а потом развалилось - опять таки виноват исполнитель.
А вот как это выглядит с той стороны экрана, с которой находится пользователь - https://habr.com/ru/post/671872/ .
А что если...
В продукт надо запиливать фичи из которых только 15-20% идут потом в рост.
Можно находить компромиссы с PO, чтобы запиливать MVP фичи "по-быстрому", но так чтобы потом их рефактор "в 2-3 раза дороже" был управляемым? Например, договориться, что фича реализуется изолированно и не выпускается из тестовой группы на основную массу, пока не переписана качественно.
?
Или он просто поставит раком нагруженную базу.
И встанет весь проект.
А как отдельная фича на пустой базе с 10 тестовыми пользователями работает ок.
ТО что теоретbчески должно встретится с реальными живыми данными и реальными пользователями уже не должно быть MVP.
А если в MVP будет дырка в безопасности что тогда?
То же, что и при дырке в обычной фиче.
Или он просто поставит раком нагруженную базу.
Нагрузочное тестирование? Динамическая конфигурация, которая позволяет отключать фичи? Staged rollout? Не, не слышали.
И похоже на стандартную разработку.
А если у вас процессов нет, то вы и при «стандартной разработке» будете визжать як порося, стоит лишь кому-то нечаянно задудосить бэк или проворонить xss.
За редкими исключениями - очень плохо, на мой взгляд, если кто-то организовал продукт так, что работа над обычными фичами постоянно требует значимых ресурсов для анализа на дыры в безопасности.
Не надо писать даже в MVP-фиче то, что поставит раком нагруженную базу при согласованных ограничениях развертывания MVP. Часто можно дешевле сделать фичу, которая "не ставит раком базу", если заранее известно, что с ней будет работать, скажем, не более 5% от общего числа юзеров и на интервале, скажем, не более 6 месяцев.
Уверены, что знаете что такое MVP, когда пишете, что он не должен встречаться с реальными пользователями и живыми данными?
Может менеджер вообще не должен приходить к "команде разработки" с какими-то идеями-пожеланиями? Тимлид/продактоунер должен быть каналом входа заданий и если они делают свою работу нормально, то донесут до менеджера и отстоят в процессе обсуждения с ним порядок исполнения задач.
Возможно не совсем в тему, но половина видео-туторов на русском по новым фичам в разработке на Youtube начинается со слов "Как-то прибежал ко мне менеджер и попросил сделать xxxxxxx, и сейчас я покажу вам как это сделать быстро и хорошо с помощью yyyyyy" Чудно это как-то )
Какая невероятно субъективная статья. Разработчики хорошие, и всегда говорят как лучше. Менеджер делает как хуже, потому что он злой и вообще саботажник.
Так не бывает, все намного сложней. Менеджер принимает решение исходя из десятков факторов, и качество кода - только один из них (хоть и важный, бесспорно). Есть еще куча вещей, которых разработчик может и не видеть. Если это заказная разработка, то без выкатки в прод "сырого" релиза следующего дня работы на проекте может и не быть. Или не будет поступления от этого заказчика и нечем платить зарплату тому же разработчику. То есть, часто в реалиях существующих ограничений, менеджер выбирает не между плохим и хорошим, а между плохим и очень плохим.
Или это остатки советского мышления, что нам нужны “ученые” которые будут молча работать? Типа “результат их работы нам нужен, а их мнение - нет.”
Ох уж это советское мышление, когда на мнение людей плевать, а важен только результат любой ценной. Откуда в головах берётся этот антисоветский бред?
Основная задача менеджера это узнать у клиента чего он хочет и объяснить программистам в задачах. ТОЧКА.
Покажите мне менеджера, который знает весь функционал продукта.
Нет, основный функционал найти компромисс между хотелками клиента и техническими возможностями. Сделать проект адекватным.
Пример: приходите вы в тюнинговое ателье и говорите удлините мне машину на 2 см, а то коленки упираются, то нормальный менеджер просто отодвинет сиденье. А не станет писать задание на удлинение тачки.
А в програмировании как раз так, начинаем костылями удлинять тачку.
Когда я был молодым и зелёным РМом, меня наняла одна маленькая, но гордая компания. Она ОЧЕНЬ хотела громко заявить о себе и выкатить к определённой дате новый продукт, который пилила почти 2,5 года. На проекте была дикая текучка манагеров и разработчиков, но меня это почему-то тогда не смутило - я был молод, горяч, хорош собой и полон энергии. Я был готов на плечах вынести проект, тем более и платить компания была готова весьма недурно.
Нееет, я не гонял сотрудников розгами и не стоял у них за спиной 8 часов. Я пошёл тыкать палочкой в СЕО, СТО и бэклог. И за два месяца их тормошения, полного разбора бэклога, нормального человеческого общения с разработчиками я понял, что проект если и успеет выйти к нужному сроку, то он ляжет уже через сутки. И ВНЕЗАПНО это знают абсолютно все разработчики на проекте, но молчат. А молчат потому, что коммерческий директор - неадекват на 146%, который и слушать не хочет ничего. Умри, но выдай к сроку продукт!
Пошёл разговаривать. Начал издалека, мягонько подводя к "Надо слушать разработчиков и исправить там, куда они покажут". На выходе же я получил истерику главы коммерческого департамента и коммдира, который плевался пеной и орал что-то бредовое.
Написал заявление уже через 2 недели и по сей день не жалею. А та самая компания сдала проект только через 4 месяца.
Мораль проста. Не всегда менеджер делает тупые вещи. Как ни грустно это признавать, но порой они - всего лишь ретрансляторы воли вышестоящего начальства, которое хочет чужими руками творить херню, а самих менеджеров в итоге увольнять / доводить до увольнения за то, что их идея провалилась.
Не всегда бывает так, что фичу есть возможность пилить до идеального состояния, придерживаясь всем принципам, и не увеличивая тех. долг. Нужно снять розовые очки :)
Мне кажется тут просто необходимо учиться правильно балансировать между идеальной реализацией и увеличением технического долга. А так же регулярно заниматься отладкой и закрытием тех. долга., и будет счастье.
Думали мы об этом. В итоге сошлись на мыслях, что всему виной капитализм в головах. Не знаю, как там было у америкосов, но наш капитализм в режиме выживания - именно это главный тормоз. А почему? Да очень просто - не на что тебе штаны поддерживать, не будешь ты думать о высоких моралиях...
Нормально делай — нормально будет