Комментарии 88
Статья прям про меня. У нас тоже поменялся технический директор (CTO). Ранее он работал продажником и начальником продажников, т.е. ничего общего с технарями он никогда не имел.
Раз, два и в продакшен - стало нормой. Всё ради сиюминутной прибыли и во вред среднесрочным планам по развитию компании. Вся инфраструктура начинает постепенно деградировать, опытные люди покидают компанию, а вместо них никого не нанимают, т.к. есть распоряжение сверху о сокращении численности персонала. Оставшиеся люди теперь перегружены работой, начинают ругаться друг с другом и терять удовольствие от работы, что ещё сильнее вредит компании.
Я с этим п.....ом тоже не смог найти общий язык. Руководители боятся ему что-то сказать, т.к. не хотят потерять свои рабочие места. Из-за этого возникают проблемы с обратной связью и коммуникациями. Руководители уже намекают, что они будут продолжать терпеть туповатого СТО дальше, а я для них становлюсь лишней головной болью.
Так что, автор, держись. Ты не один такой. Я тоже нахожусь в такой же ситуации.
Я сидел и думал — когда именно я превратился из уважаемого специалиста в динозавра, тормозящего «гибкие бизнес-процессы»?
У меня такие же ощущения. Все вдруг "переобулись" и "прогнулись" и согласны с новыми порядками, которые приведут компанию к упадку. Я не готов продать свои принципы и подстраиваться под нового СТО.
Тогда зачем оставаться там работать? Если работаете, выполняете задачи - значит Вас устраивает текущее положение дел.
С чего Вы взяли, что если человек там до сих пор работает, то его все устраивает???
Моя ситуация, на работе выгорел, да так что валил собеседования за собеседованием, прям, начинается собес, меня трясёт, мысли путаются, в итоге отказ.
Целый год не мог никуда сдвинуться. Отпустило, ушёл.
А ещё бывает что ты крутой, очень крутой специалист, тебе нравится делать определенные вещи и ты умеешь делать это хорошо, но рынок не нуждается сейчас в тебе, т.е. нету вакансий, никому не нужны твои скилы, хочется другой стек и ты вынужден переучиваться, это тоже время.
Новая беда, это АйТи ипотека, у меня есть знакомый который конечно ее взял, не могу его в этом винить, но каждые три месяца будь любезен, справочку в банк что работаешь в АйТи компании. Опа, и круг устраивающих тебя вакансий резко сузился.
Зачем оставаться работать? Вопрос подразумевает ответ - сменить работу. Т.е. стратегия избегания проблем. "Появился начальник самодур? Ну хорошо, уволюсь." Мне кажется, что у опытных людей всё же немало используется майндсет "решать проблемы", а не "убегать при первых же сложностях". Поэтому сначала пробуют решать, а потом уже менять работу
Если начальник реально самодур, то единственное, что можно попробовать порешать - это прийти лично к гендиру (ну или кто там самый главный) и прямо сказать "он самодур, я так работать не готов, так что или он, или я". А устраивать "игры пристолов" - это не для всех вне зависимости от количества опыта. Так, если меня затягивает в подобную разборку, я поневоле начинаю ненавидеть всех причастных (почти как в "Лиловом шаре") и ситуацию в целом. И могу внезапно для себя устроить публичную словесную порку причастным (включая начальство), причём даже не успев подумать, что это происходит публично. Похожее происходит, если меня начинают заставлять писать "в стол", постоянно внезапно переключаться и внезапно заставлять выкатывать в продакшен прямо "из стола", без тестирования и со словами "это должно быть готово вчера". Я такое проходил, пытался справляться (а-ля "решать"), в итоге выгорел к чертям, устроил публичную порку начальству, был уволен сам, а немного погодя и начальство (видимо, тот гендир в подобных ситуациях тоже ненавидит всех причастных). Имхо, лучше не выгорать, и лучше никого/ничего не пороть - лучше отслеживать ситуацию, и при регистрации самодурства и/или нарастания количества всякой невыносимой фигни резко начинать работать над максимально стремительным уходом (что при запущенном выгорании становится максимально проблематично). Но опять же, психотипы очень разные - кому-то, наверное, и постоянная ситуация срача и срывающихся дедлайнов в кайф.
Если начальник реально самодур, то единственное, что можно попробовать порешать - это прийти лично к гендиру (ну или кто там самый главный) и прямо сказать "он самодур, я так работать не готов, так что или он, или я".
И это звучит как решение проблемы. Ну, её попытка по крайней мере - вы как разраб ниже начальника будете, поэтому проблему решить можете только через начальника вашего начальника, ибо ваша позиция не предполагает наличия такого количества ресурсов и полномочий для самостоятельного решения проблемы. Если проблема не решилась и/или вы заметили, что и начальник начальника туда же, то тогда уходить. Но уходить сразу, так легко сдавшись, даже ничего не предприняв - как-то не очень
Всего-то надо внедрить Минерву, как в данном посте и все наладится
Я не готов продать свои принципы
Может, я чего-то не понимаю, или я просто нехороший человек... Извините, если невзначай задену ваши принципы - я просто не особо понимаю, что за принципы такие.
С моего насеста: это профессия, а не религия. Любая профессия (кроме религиозной, но это не точно) выбирается человеком для того, чтобы зарабатывать деньги - как можно больше денег, - при этом делая то, что получается делать хорошо и не выгорать при этом, а в идеале даже получать удовольствие и от процесса, и от результата.
Т.е., иметь возможность работать с комфортом и удовольствием, не выгорая и зарабатывая достаточно, чтобы не дёргаться - это, наверное, мои главные принципы по отношению к работе.
Они подразумевают, что у меня есть интерес к работе и проектам бизнеса, а также симпатия к бизнесу и персональное желание, чтобы бизнес зарабатывал больше (особенно если бизнес ясно даёт понять, что его успех прямо отражается на моём успехе, причём в деньгах, а не в "спасибо").
С другой стороны, у бизнеса могут быть разные этапы жизненного цикла, на которых необходима разная скорость.
Я не бизнесмен, и слава Богу, что вот эти нюансы - скорость внедрения фич, скорость внедрения багов, скорость устранения багов - должны рассчитываться не мной, а менеджерами моих менеджеров. Хотел бы сам рулить, не продавал бы себя за деньги, чтобы мной рулили.
Поэтому, когда менеджеры говорят "тут надо тяп-ляп и в продакшен", а "сейчас надо потратить столько, сколько нужно на планирование, архитектуру, превентивный багхант, рефакторинг и т.д." - если у меня есть проф. соображения, озвучиваю, но прям дотошно понять их мотивацию в моменте даже не пытаюсь. Отдаю под козырёк и тихо радуюсь, что они (эти менеджеры) у меня есть, чтобы беспокоиться о всей этой суете.
Имхо, если отпустить всякие "принципы" типа "отступы должны быть только такими", "фигурные скобки в условиях надо ставить только так", "НИКОГДА нельзя нарушать цикл релизов, чтобы пропатчить из дев сразу в стэйджинг и продакшен", "функции должны быть не больше/не меньше ТОЛЬКО такого размера" и т.д. и т.п. - жить и работать становится легче.
Принципы = ценности. Предаёшь ценности ради бабла — предаёшь себя. Будешь богатым, но будешь пустым. А в конце жизни может быть немного грустненько от выбранного пути. Бабло для интеллектуального человека не самоцель, но ресурс.
Я не в вакууме спрашивал, а в контексте:
Все вдруг "переобулись" и "прогнулись" и согласны с новыми порядками, которые приведут компанию к упадку. Я не готов продать свои принципы и подстраиваться под нового СТО.
Вот это конкретно что за принципы?
Лично я пока не в курсе, т.к. сам не разбираюсь в управлении бизнесом и бизнес-процессами, у меня другая профессия и другие интересы. Я тоже не хочу, чтобы бизнес, на который я работаю, шёл к упадку. Должен ли я ради этого учиться управлять бизнесами разных размеров на всех стадиях их развития, чтобы иметь возможность рационально и объективно оценивать текущую ситуацию и аргументированно разнести текущую политику СТО перед хозяевами бизнеса, если увижу, что она ведёт бизнес к упадку? Нет, и ценности тут не при чём.
Это не говоря о том, что я наблюдал и наблюдаю разные бизнесы на разных этапах своего жизненного цикла, и вполне понимаю, что бизнесу часто надо лавировать, проявлять гибкость, и это также включает в себя периоды, когда приходится идти на создание технического долга в качестве платы за быстроту в решении сиюминутных задач. И если я вижу, что менеджмент, принимающий такие решения, ясно понимает и осознанно оценивает (явно лучше, чем я) стоимость и отдачу, то всё хорошо, даже если сейчас от меня требуют "фигак и в продакшен". А если не вижу - то откуда мне знать, что этого (понимания и осознанности) нет? Я-то не обладаю ни соответствующей квалификацией, ни всей полнотой информации - о динамике с текущими клиентами, с потенциальными клиентами, с финансовой ситуацией бизнеса и т.д. и т.п.
Если же бизнес реально тонет, т.к. не умеет в адекватных менеджеров, то никакой технарь его не спасёт. Максимум, можно аккуратно выразить свои опасения доступному начальству. В адекватно устроенном бизнесе практически любой работник регулярно имеет шансы донести своё мнение до практически любого уровня управления. Если бизнес устроен неадекватно, то я всё равно его строить не умею, и не хочу уметь, т.к. другие интересы и время не резиновое.
Предаёшь ценности ради бабла — предаёшь себя.
Есть список этих ценностей? Напр., разновидности водопада и аджайла это не ценности, а техники управления процессом. Дотошная документация вот прямо сейчас, пока из-за отсутствия критического для него фичера или багфикса сливается дорогущий клиент - это тоже не ценность, а, скорее, наоборот. Тот или иной стиль структурирования кода - тоже не ценность, а дело вкуса и конвенции на рабочем месте. Привычка к существующим методам управления, из-за которой их существенное изменение кажется разрушительным (в первую очередь из-за необходимости самому перестраиваться) - тоже не та ценность, к которой можно аппелировать с позиции морального превосходства.
Вот лояльность платящему работадателю - в мере, обусловленной договором - это ценность. Но эта ценность подразумевает субординацию. Не постоянные переработки, не обожание фирменных логотипов и прочий корпоративный фанатизм, а понимание своего места в процессе и доверие бизнесу идти своей дорогой, не спрашивая у меня, наёмника, разрешения.
Наконец, временный союз между наёмником и бизнесом это не семейные узы. Совершенно нормально каждому пойти своим путём, если где-то что-то не срастается. И если это происходит с эмоциональным разрядом уровня "предательство", то, имхо, вряд ли такое можно назвать нормальными рабочими отношениями.
Я не программист, но постараюсь пояснить позицию. Например, для меня важен острожный, сбалансированный стиль управления, когда я вижу что директор поощряет наглых сотрудников (которым важнее формальные показатели и выгода здесь и сейчас) и подавляет тех, кто мыслит на перспективу, тогда становится понятно что эта работа не для меня.
Рассказываю из своего опыта, т.к. видел процесс этого распада изнутри. Когда человека с системным мышлением и фундаментальным подходом подавляли ушлые коньюктурщики с потворства начальства.
Для меня ценность работать в команде профессионалов, где каждый занимается тем, что у него лучше всего получается. Когда твоя работа становится полезным для общего дела. А не когда работу замещают интрижки и подковёрные войны за лояльность начальству. Я не буду работать в таком коллективе, потому что это будет предательство моих ценностей и это не компенсируется деньгами.
Такое ощущение, что теперь это сплошь и рядом. У нас так же. Очень забавно наблюдать, как технический директор час выслушивает презентацию новых фич во флагманском продукте компании, а потом спрашивает: а что такое SQL? (или аналогичное). Мы уж как-то привыкли :)
Я не готов продать свои принципы и подстраиваться под нового СТО.
просто не слушайте его и все
ну уволит ну и что
или не уволит
Увидел фразу: "и если не покажем рост через полгода". Уверен, что если бы не показали рост - позиции нового шефа могли бы очень серьезно пошатнуться. Да даже отсутствия роста зп / премии было бы очень болезненно. Поэтому да - никакой стабильности и красоты, только буйный рост и куча отчётов о достижениях, которые говорят "видите, я могу больше, чем прошлый начальник".
PS: А вот это меня ещё больше убеждает в моём мнении: "видимо, где-то мы нашли правильный баланс, хоть и спустя время." - это не вы нашли баланс, а он перестал бояться за своё место. ;)
Увы, частая история. Потом кодовая база скатывается в не поддерживаемое, завязанное друг на друга гумно. Внедрение чего-то нового становится "золотым", а инциденты становятся вначале ежедневными потом ежечасными/ежеминутными, в зависимости от нагрузки. И или компания находит ресурс на "все переписать" или бизнес потихоньку глохнет из-за потери лояльности пользователей.
Но как правило, к этому моменту эффективного "сова-менеджера" уже в компании нет.
Но как правило, к этому моменту эффективного "сова-менеджера" уже в компании нет
Все так, он перепрыгнул с повышением в следующую компанию :)
Так ровно также стоит менять фирму и технарям, почему нет?. Вся проблема то в статье в очень сильном эмоциональном влипании специалиста в проблемы фирмы. "Надо делать хорошо во что бы то ни стало, даже покрывая все неоплачиваемыми переработками" - нет, не надо. Это проблемы фирмы и ее руководителя. Не слушает рекомендаций - ну ок, его право и его последствия.
Новый CTO продвигал Flask
А выбора-то у вас и не было.
Нужен компромисс - писать быстро и относительно нормальный код. Который потом можно будет отрефакторить.
Не может человек, шарящий в архитектуре, писать полную хрень, даже если что-то надо очень быстро запилить.
К сожалению статья выглядит неправдоподобной. По пунктам:
1. "Мы сжигаем деньги инвесторов" - внезапно оказалось? А до этого не сжигали? Вообще это модель работы стартапов, а у компании судя по описанию уже есть работающий продукт, раз даже платежный модуль для него сделали, и вообще компания давно работает.
2. "Компания серьезно меняла свою бизнес-модель, и скорость вывода продуктов на рынок стала жизненно важной" - и ни слова об этой бизнес-модели и причинах ее изменения. Вот так жила-была компания, зарабатывала деньги и внезапно решила поменять бизнес-модель. Причем на такую, при которой даже платежные модули не нужно тестировать.
3. Несколько раз упоминалось о том, что фиксы и рефакторинг будет потом. Что мешало сразу спросить: "Когда потом?" и написать тут свои выводы? Потому что одно дело если у СТО (который вообще-то технический директор, и должен понимать что полгода-год такого кодинга и дальше никаких "быстро в продакшен" не будет, потому что 9 женщин не родят ребенка за месяц) есть конкретные сроки и план, например: "Нам нужно в течение полугода вывести продукт на рынок и показать рост, после чего мы переходим в спокойный режим и выделяем одну неделю в месяц на рефакторинг и лучшую архитектуру". А если же он просто говорит "потом-потом", то очевидно что никакого плана у него нет, и нужно честно это признать.
4. Автор принимает за аксиому что "бизнесу нужно быстрее", даже не анализируя - действительно это нужно или кто-то решил себе бонусов заработать. Понятно что это не его работа, но это позволит ответить на вопрос "С кем я работаю", ведь это важно программисту.
Да это не реальная статья, а обычная корпоративная рекламная мертвечина, написанная отвратительным, плоским языком (ChatGPT?), от которого начинает мутить уже к середине материала. А-ля "мы столкнулись с серьезным вызовом бизнесу, но при помощи <Название_рекламируемого_инструмента> и глубокой внутренней перестройки струи нашего шоколадного фонтана стали еще толще".
Год назад прочитал "анекдот". В нем описана следующая тенденция: в 40-х годах был один компьютер и один программист, и им был Алан Тьюринг. В 50-х десятки компьютеров и программистов, и ими были лучшие умы человечества. Потом с каждым десятилетием расло количество и того, и другого, средний программист поначалу имел докторскую степень, потом PhD, потом диплом магистра, потом бакалавра. Заканчивается это наблюдение тем, что сейчас идут споры о том, нужно ли вообще формальное образование программисту.
Самым спорным в этом наблюдении является только утверждение про Алана Тьюринга. И вот что интересно, спустя пару месяцев после прочтения этой горькой шутки я заметил, что снизу постучали: мне попался на глаза спор в соцсетях, где люди на полном серьезе утверждали, что высшее образование программисту даже вредит. Дескать, после 5-6 лет выпускник все равно ничего не знает, зато обучившись полгода на курсах условного питона человек без высшего образования может за те же 5 лет получить солидный опыт.
Это я все к чему: снова я про Cynefin Framework. Алан Тьюринг и лучшие умы человечества -- это Chaos и инновации, появляющиеся из него как Афродита из пены морской. Потом Chaos перетекает в Complex и программирование из искусства становится наукой. Далее Complex преобразуется в Complicated, и программирование становится индустрией, где важны качество, сроки, контроль, и т.д. Затем Complicated переходит в Simple, появляются low-code и no-code решения, войти-в-айти, индустрия становится коммодити практикой. Следующий этап, который начался где-то в 2020, когда пандемия нас сильно к нему подтолкнула -- это переход из Simple в Chaos. Сложность задач, которые необходимо решать, уже невозможно уменьшить, а контроль над процессом мы давно потеряли. Собстенно об этом и статья. Очень жаль, что автор поддался и согласился с этим трендом.
Ждем кульминации хаоса. Это может быть а-ля Чернобыль, когда инженеры (чья профессия была в том, чтобы чтить законы физики) пошли на поводу у "клиентов": коммунистической партии, и попробовали закончить опасный эксперимент в первомаю. Это может быть очередная пандемия: с антиваксером Робертом Кеннеди в роли министра здравоохранения США она может пойти оттуда. Или может быть киберсекьюрная дыра: по моим ощущениям здесь пузырь тоже напрашивается лопнуть. Мало ли что еще, и вот когда случится, снова пойдем по маршруту Chaos-Complex-Complicated вспоминать, что такое архитектура и искать людей, которые еще не забыли, что такое инженерный подход.
Заканчивается это наблюдение тем, что сейчас идут споры о том, нужно ли вообще формальное образование программисту.
Это было 15 лет назад, сейчас уже школьники кодят лучше джунов.
Мысль как-то была выражена короче. Кажется, Михаилом Жванецким. Концептуально: "Количество интеллекта на планете - величина постоянная. А население-то растет..." 😄
Уже третья статья попадается про Минерву и все по одной схеме: как было -> как стало(проблема) -> как побороть... И вот тема вроде интересная, и советы в целом можно применить, и понятно , что рекламный пост, НО чувство, что текст написал ИИ, а не живой человек, портит все приятные ощущения от статьи и от компании вцелом. Кажется, будто сказку читаешь и думаешь, раз история выдумка, сработает ли в итоге предложенное решение?
Я бы хотел добавить несколько коротких предложений/комментариев на данный счёт: я инженер-проектировщик, например, и столкнулся с тем же самым, что и автор – "надо сделать тяп-ляп и как-нибудь, желательно по-быстрее, а потом поправим". Если сразу перейти к сути: я понял, что слишком много времени зацикливался на изящности исполнения решения по какому-то рабочему вопросу, в то время как мои коллеги просто выполняли работу и давали результат за результатом, и в критерии оценки моего КПД и моих коллег я отставал, ибо за единицу времени они выполняли больше, а соответственно приносили больше прибыли. После осознания всего этого я решил изящность и перфекционизм включать как тумблер или переключатель(света) – по необходимости, когда замечаю что % ошибок растёт или можно часть работы автоматизировать(для этого естественно нужно сделать 1 или 2 раза идеально). Итог в итоге: перфекционизм оставляйте для искусства, работа это всего-лишь работа
Есть области, где перфекционизм критически важен. Например, в инфобезе. Одна ошибка и и ты ошибся.
Прочитал статью - решил больше никогда не тратить время на хабр
Как-то режет взгляд великое архитектурное решение использовать Flask / Django. Ну тяжело мне представить менеджера, который знает о Flask и одновременно не понимает, что придется переписать кодовую базу в случае его выбора.
Знакомо, конечно. Проходили такое. Но у автора много рационализаций, желания все объяснить как-бы получше, хотя причины подобных проблем могут быть примитивными, психологическими (например, борьба за власть над принятием решений на проекте). Или под спудом могут изматывающе сидеть желание свалить поскорее и ленивое/безответственное желание ехать на "больной кобыле" дальше. А думать наперед сегодня вообще не модно, особенно экспертной группой. Да и начальство в наши дни часто отрицательно отбирается по крысиному принципу "кто первый тот и босс", поэтому судьбоносные обсуждения часто похожи на игру в одни ворота. Себя хорошо бы всегда пинговать вопросом "это вообще мое?", "чтобы не было мучительно больно за бесцельно прожитые годы" (Николай Островский)
Я привык делать хорошо, а не быстро.
Подобные скоропалительные убеждения нужно изживать, они уродуют реальность так, что потом концов не соберешь.
Искренние соболезнования автору. К сожалению, как показывает практика, эти потуги с нахлёстыванием умирающей лошади в конечном итоге приведут к провалу проекта. Но руководству, как правило, виднее, какие работы приоритетнее: где можно снять сливки и выдать полноценное решение, а где достаточно рабочего демо, оставив заказчика с тем как оплачено, так и *но
И да, тут напрашивается коммент из предыдущих статей про связь продукта от минервы и потенции :) Т.к. связь инструментов и стиля управления примерно никакая.
ПС: коммент тут
https://habr.com/ru/companies/minerva_media/articles/894306/comments/#comment_28096010
Зачем я вообще прочитал эту невыдуманную историю копирайтера, который учился на текстах ChatGPT. Верните мне 8 минут моей жизни.
Для начала надо определиться, что же на самом деле приносит компании деньги, красивый код или готовый продукт.
А знаете где ещё есть невыдуманные истории из жизни боевых разработчиков...
"Новый директор пришёл из Сколково" - А что ещё можно ожидать от таких людей, да ещё от менегеров по продажам.. Трёп да показуха. Впрочем, когда слышу слово "инвестиции" всегда чего-то подобного и ожидаю..
Короче Минерву стороной обходить надо, простой в KPI бэкендера это дичь, он вам что SRE. Ещё и рефакторить по вечерам. Race на платежах допустить - ну типичные вкатыши после курсов, чё сказать, а на кодревью наверное в отступы упарываетесь и имена переменных, вместо того чтоб бизнес-логику проанализировать и заранее проблему увидеть. Я б такие статьи вообще не писал, если нанимать планируется кого-то ступенью выше миллионной армии вайтишников. Если автор живой человек, выдайте ему право вето на всё и прибавку, он один походу шарит))
Статья, конечно, нейрослоп, но ситуация вполне реалистичная. Правда у меня такой тимлид был изначально, еще и с другого стека программирования пришел. И это очень печальная ситуация, потому что количество говнокода в итоге выросло до такого объема что реализация новых фич заключалась в добавлении кучи костылей и подпорок там где их быть никогда не должно потому что без переписывания всего с нуля по-другому было невозможно.
История с хэппиендом только потому, что рекламная. Один мой друг™ бывал в такой ситуации, и кончилась она тем, что хорошие разработчики просто ушли туда, где так откровенно не исповедуют принцип "херак-херак и в продакшен", а оставшиеся накопили техдолг до того уровня, когда разнообразные сбои и длительные простои стали регулярным явлением, и любые изменения в систему вносились медленно и сложно, после чего акционер передал разработку подобной системы другой команде, а проблемный проект просто закрыл.
Ваш СТО всё прекрасно знает и понимает, и работает на свои KPI. Он получит премии за это и уйдёт на другой проект.
Автор, ты не привык к закулисным играм, которыми заняты люди на подобных должностям, поэтому тяжело противодействовать: нет понимания того, как это можно сделать, ведь ты не этим занимаешься в работе.
Либо борись в этим, используя грязные способы, либо делай вид, что ты согласен со своим СТО, давай ему минимум, необходимы для того, чтобы оставаться на работе, а сам делай своё дело.
У вас разные приоритеты. Ты за красоту, чистоту и правильность, а он за KPI.
MVP First, и точка.
Большая компания, инертная среда, колоссальное сопротивление изменениям даже тогда, когда изменения точно принесут большие деньги. Если там делать всё "по правилам из методички", ваше изменение морально устареет раньше, чем его внедрят. А если нечего показать - так вообще, всё умрет на этапе согласований.
Пример. Огромный софт, сотня модулей, сложные связи. Всё собиралось отделом руками, паковалось в архив, админами доставалось из архива и раскладывалось в полуручном режиме по нодам. Спрашиваю, а какого дьявола тут нет ci/cd, почему каждый релиз - это две недели безумного аврала? "Ой нет, это сложно, соседи уже пятый год внедряют, и конца этой эпопее не видно!" Говорю, а дайте мне сервера и месяц времени, причем не полный день, а то, что от основных задач остается. Дев-зона не зарегулирована, дали. Через месяц был потрясающий вау-эффект, что две недели гемора превращаются в нажатие пары конопок и часа ожидания. "А чо так просто? Чо соседи пять лет делают?" Перфекционируют соседи. Дальше, когда показы прошли с оглушительным успехом, были наняты девопсы, которые мой дендрофекальный MVP на жаве и питоне переписали красиво, с учетом всех требований и современных инструментов. На это ушло полгода, потому что MVP содержал все крупные требования, мы уже знали, чего хотели.
В стартапе вообще, сделаный на скорую руку прототип - гарантия выживания. Пока ты вылизываешь нечто, конкурент моолниеносно вываливает дерьмо, захватывает рынок, потом итерациями вылепливает из добреца некий продукт. И пока перфекционисты делали красиво, рыночек уже заняли, их красивый продукт улетел в помойку.
Как-то так
MVP First не работает если для компании первое попавшееся решение является окончательным. То что вы наговнокодите в MVP так и останется навсегда и будет обрастать костылями и подпорками. Таких ситуаций очень много, особенно когда речь идет о какой-нибудь компании с основным бизнесом вообще никак не связанном с IT. Даже если на без этого IT все встанет колом.
То что вы наговнокодите в MVP так и останется навсегда и будет обрастать костылями и подпорками
"Костылями и подпорками" точно также обрастает ваша (на ваш взгляд) идеальная архитектура (она, кстати, не идеальная, а переусложненная и требующая много времени на поддержку).
Любой старый код обрастает "костылями и подпорками. Любой. Это неизбежно.
СТО это понимает, а мамкин пирожочек (только недавно вылупившийся из яйца, прочитавший теоретиков вроде Мартина или Фаулера и считающий себя умнее других) - нет.
На основе моего достаточно обширного опыта разгребания чужих авгиевых конюшен (и того как меня не слушали и их устраивали когда можно обойтись было без этого) могу ответственно заявить что множитель количества костылей и подпорок всегда прямо пропорционален количеству раз когда люди решали что что-то делать нормально на начальных этапах разработки им западло по той или иной причине. И в итоге это превращалось в неподдерживаемое нечто где нужно залезать под капот всего чего только можно чтобы это хоть как-то работало. Ну или, если повезет, переписывалось так как изначально предлагали.
Мир не черный и белый. Нет идеальной архитектуры, но есть набор шишек и граблей, которые нормальный специалист обязан еще до того как что-то уйдет в разработку предвидеть и не допустить. Потому что потом либо самому, либо коллегам придется ломать мозги с этим. Всякие system design у сеньеров-помидоров не просто так на собеседованиях спрашивают.
Вы описали крайние условия, когда MVP действительно является решением.
Есть так же другие крайние условия, где MVP является причиной гарантированного провала проекта в совершенно недалеком будущем на уже на второй итерации жизненного цикла и я такие видывал.
Реальный мир все же сложнее этой одномерной линейки MVP - НЕ MVP.
Задача нашего брата понимать что проект MVPшный или становится таковым не по случайной ошибке, а систематично и иметь смазанные лыжи к часу X.
Писал статью на эта тему:
К сожалению, бизнес не всегда знает или понимает, чем занимаются его сотрудники. Бизнес хочет результат, но бизнес не знает о префекционистских тараканах, которые зачастую живут в головах его персонала. Начитавшись «умных» книжек всяких айти-теоретиков чувство перфекционизма у разработчиков излишне гипертрофировалось, что вылилось в некую форму поклонения программному коду и нивелированию основной причины, для которой этот код пишется.
Чем больше вы мастурбируете на красоту кода, на стандарты кодирования, тем меньше у вас остаётся времени на самое важное — на осознание полезности этих действий.
Идеальный код — это иллюзия, особенно если вы пишите его в промышленных масштабах. Функции инспекции, которые зашиты в любых современных профессиональных IDE, без труда могут найти в большом работающем проекте сотни ошибок, напоминаний и предупреждений. Становится ли от этого продукт, выполняющий свои функции, сильно хуже? Вряд ли.
Код должен работать и приносить пользу, на него не нужно молиться, его не нужно бесконечно вылизывать и любить. Я в очередной раз хочу дать ссылку на статью «Автор библиотеки, от которой зависит половина сайтов, сидит без денег» — она лишний раз демонстрирует, что код сам по себе — не больше чем текст на экране. Важен не код, важен продукт и результат работы продукта. Даже самый чистый и вылизанный код не стоит ровным счётом ничего (его на гитхабе как дерьма за баней). А вот излишний перфекционизм служит предиктором симптомов психического расстройства.
Автор пишет:
иногда я становился тем самым душнилой, который на каждом собрании говорил о правильной архитектуре, паттернах проектирования и важности чистого кода
Автор, без обид, но таким обычно говорят "найди себе женщину". Не буквально, но это можно перефразировать как "займи себя чем-то". Вы из работы и карго-культа "паттернов" сделали себе самоидентификацию.
Ничего, с возрастом пройдет и к 40 годам будешь пушить в прод любой говнокод, лишь бы отстали.
На самом деле всё правильно. Так оно и работает в жизни: хочешь выжить в мире высокой конкуренции - тогда забудь о личном психологическом комфорте. Психологический комфорт программиста для бизнеса представляет невысокую ценность. Особенно когда это вступает в конфликт с прибылью.
Особенно когда это вступает в конфликт с прибылью
Более того, это не только в it так. Говнокодят на скорую руку что бы срубить бабки почти все. Из личных наблюдений:
Капремонт многоквартирного дома подрядчиком - спустя полгода косяки вылезли, ибо делали как можно быстрее. Недавно упала труба отведения осадков, т.к. все болты тупо не закручены были.
Нанимал строительную бригаду в квартиру для отделки - тоже накостылили, вкрутив саморезами напольные плинтуса прямо в штукатурку, пришлось переделывать самому.
Автосервисы. Если бы они делали все четко по регламентам, как в книжках описано, то там бы х2 стоимость была (смазка на каждый болт, промывка после каждого демонтажа агрегатов спецсредствами и тд).
Хотелось бы заслушать другую сторону. Потому что с её точки зрения может выглядеть так: фичу, которую конкуренты выводят за месяц и захватывают рынок, мы пилим пол года и выпускаем, когда она уже никому не нужна. У нас, конечно, красивый код, но деньги закончились, всем спасибо, все уволены.
В вашей модели разработка фичи заканчивается с ее выпуском. Но в том и отличие инженера от автомеханика, что горизонт планирования последнего заканчивается с уходом клиента домой (ну, может, еще пара дней гарантии), а у первого следующую фичу приходится делать на костях технического долга предыдущей. Как следствие -- кладбище стартапов с одной выпущенной фичей.
В вашей модели разработка фичи заканчивается с ее выпуском.
Кто вам это сказал? Демагогия. Ложная альтернатива, ложная дилемма.
Но в том и отличие инженера от автомеханика, что горизонт планирования последнего заканчивается с уходом клиента домой
Отличие синьор инженера от мидла как раз в том, что он не просто пилит фичу в соответствии с букварями, а разбирается и понимает, кому и зачем она нужна и как с ней будет работать пользователь. А вовсе не в количестве изученных фреймворков. Синьор понимает или, по крайней мере, пытается понять задачи бизнеса. Мидл инженеру, как вы совершенно верно заметили, абсолютно не интересно, что будет с фичей, после того, как он её написал. Он своё дело сделал и пошел домой, он молодец, ему вообще наплевать, откуда деньги берутся у компании. Именно поэтому в синьорских резюме западного образца принято писать про импакт: "я запилил фичу, это сэкономило компании Х денег/привлекло Y клиентов". Если в вашем резюме написано: "я запилил фичу, освоил фреймворк и там суперчистый код", - то с таким резюме поиски работы будут затруднены. От этого всегда бомбит у наших программистов. Они не знают, какой импакт от их деятельности, их это никогда не интересовало, они просто пишут код, а на счёте 2 раза в месяц появляется зарплата. Это, в целом, неплохо, если ты мидл, но мидлы не должны API проектировать.
Это прямо вот классический пример. Спрашиваешь человека: "почему ты сделал вот это вот так?". А в ответ тебе говорят про технические сложности, про чистый код, про паттерны и разделение ответственности и т.д. Родной, ты сделал плохо, потому что пользователю неудобно, ты сам попробуй попользоваться тем, что ты написал. Потому что когда ты занимался разработкой, ты думал не о пользователе, не о продукте, а о красоте технического решения в первую очередь. Конечно, не надо писать тяп-ляп говнокод, ни в коем случае, но не надо и телегу ставить впереди лошади.
Зачем ты пилил фичу, чтобы что, чтобы эго своё потешить за счет компании, кому и как она помогла? Почему ты считаешь, что заниматься конечной архитектурой API, разработкой документации к API, разработкой курсов обучения использования этого API, и всё это в течении полугода, это то, что нужно компании прямо сейчас? Почему ты считаешь, что твои гипотезы верные, ведь мы пока даже до конца не понимаем, что именно нужно пользователям? Может мы сначала выпустим бета-версию за месяц без гарантий обратной совместимости и с несколькими примерами в качестве документации, соберём фидбэк, реальные сценарии использования, выявим потребности, а потом уже всё запроектируем всё как надо? Ни разу не работали с API, где дофига всего понаписано, половина понаписанного используется примерно никогда, но упущена пара важных мелочей и пол интернета обсуждают, как это обойти костылями, потому что разработчик не может вкорячить это в рамках прекрасной чистой ахитекруты существующего решения и не хочет тратить ещё 100500 денег на перепроектирование всего с ноля?
Вот где демагогия:
А в ответ тебе говорят про технические сложности, про чистый код, про паттерны и разделение ответственности и т.д. Родной, ты сделал плохо...
Чистый код -- это как чистые руки хирурга: необходимое, но недостаточное условие качественной работы. Из ваших же рассуждений можно понять так, что чистый код -- автоматически плохой.
Может мы сначала выпустим бета-версию за месяц, соберём фижбэк, реальные сценарии использования, выявим потребности, а потом уже всё запроектируем всё как надо?
И часто вы потом проектируете как надо? Если да, то снимаю шляпу и присылаю вам резюме. На практике я никогда не видел, чтобы этим хорошим планам было суждено сбыться.
Чистый код -- это как чистые руки хирурга: необходимое, но недостаточное условие качественной работы.
Нет, конечно же. Вообще не необходимое. Необходимое для чего, кстати?
Из ваших же рассуждений можно понять так, что чистый код -- автоматически плохой.
Из моих рассуждений можно понять, что я убил Лору Палмер, но я ничего подобного не говорил.
И часто вы потом проектируете как надо?
Конечно, в этом смысл. Кстати, если вам нужно именно авторитета послушать, вот что писал Дональд Кнут, например: "Premature optimization is the root of all evil (or at least most of it) in programming." Это, конечно, не про чистый код, но идея та же.
А самое смешное, что не менее часто не перепроектируем. Потому что оказывается, что фича нафиг не упёрлась и от нее отказываемся. Только выяснили мы это за месяц, потратив минимум денег. А могли бы пол года пилить с тем же результатом.
Разработчик не является владельцем продукта, поэтому создавать идеальный код не нужно, так как на это уйдет времени больше, чем выделяется бизнесом.
Перфекционировать надо в том, что за отведенное время надо создать максимально лучший код, а там хоть трава не расти. Ну и рабочий день строго по графику. На продукт плевать, на код нет.
На Титанике пассажиры тоже думали, что платят за комфорт и скорость. Так же думала и команда, включая радистов, которые отстукивали телеграммы на материк и проигнорировали пять нотификаций о наличии айсберга. Как потом оказалось, качество сервиса должно было быть не столько в разнообразии еды в ресторане, сколько в отслеживании технического долга процессов на судне...
Используя вашу аналогию, то разработчика-перфекциониста выкинули бы за борт еще до встречи с айсбергом.
Вы не хозяин, не владелец, не СТО, не архитектор. И если вам не удалось "достучаться" до руководства то выхода всего три: уйти, остаться и выгореть или остаться + мой метод. Выбирайте...
Ну о том собственно и речь, что людей, способных предотвратить катастрофу, не любят и до управления не допускают. У Талеба в "Черном лебеде" это разобрано на гипотетическом примере человека, предотвратившего 9/11 и сгинувшего в безвестности.
Есть еще иные возможности, кроме озвученных вами, например, обосноваться ближе к спасательной шлюпке.
Касательно вашего метода -- он хорош тактически. Да, можно стать гибким оставаться подолгу на одном месте. Но вот перейти на другое место (с целью увеличения зарплаты) становится все сложнее.
Про свой любимый Cynefin Framework я уже рассказал выше. Теперь о другой модели: пирамиде потребностей Маслоу. Она описывает иерархию человеческих потребностей, начиная с базовой (еда и все, что требуется телу), потом потребность в безопасности, потребность в социуме, потребность в признании, и вплоть до самоактуализаии (что бы это ни значило). Так вот эта модель весьма интересно проецируется на то, что мы создаем, в данном случае код и продукт. Базовый уровень -- потребности бизнеса в текущий момент. Уровень безопасности -- это уверенность в том, что мы сможем эти потребности удовлетворять в будущем. Уровень социализации -- понятный код и модули, которые могут взаимодействовать друг с другом. Признание -- эффективность кода и качество продукта. Самоактуализация -- переиспользование, опенсорс, и т.д. И, как и в случае с пирамидой потредностей Маслоу, наш код/продукт растет по мере приобретения свойств каждого уровня и деградирует при потере этих свойств.
Эффективный сова-менеджер тянет проект в базовый уровень без надстроек. Жадный подход "здесь и сейчас", "после меня хоть потоп". Аналог бомжующего маргинала, думающего лишь о том, как набить желудок. Если хоть немного задумываться о завтрашнем дне, то люди начинают ценить страховки, постоянность места работы, дают образование детям, переезжают в спокойные районы или на худой конец перестают есть некачественные продукты: отсутствие проблем завтра они ценят выше экономии сегодня. В случае кода/продукта это выливается в хорошие практики и устранение технического долга. Уровни выше я даже описывать не буду, мое отношение к описанному в статье становится понятным уже по описанию первых двух.
Но в реальном мире существуют конкуренты. Поэтому, задумываясь о верхних ступенях пирамиды, не стоит забывать, что сначала надо построить самую нижнюю. И тогда, возможно, повезет, и среди тысяч конкурентов, удастся занять место #1, с максимальным числом ступеней.
Именно. Но давайте продолжим аналогию. Конкуренция тех, кто борется за выживание на первом уровне, очень напоминает стычку бомжей у мусорного бачка. У людей бывают разные ситуации, но переход с первого уровня на второй должен сопровождаться некоторыми инвестициями и искоренением дурных привычек. Студент может жить от стипендии до стипендии, но при этом инвестировать время и силы в образование: не за горами его выход на второй и далее уровни. Те же, кто, находясь на базовом уровне (или даже только пытаясь его удовлетворить) берут микрозаймы, никогда не закрепятся даже на первом уровне. Технический долг -- он сродни денежному, и его нужно очень аккуратно контролировать.
Если возвращаться к статье и принять за правду то, что там написано, то выходит несколько иной коленкор. Изначально компания уже плотно находилась на втором-третьем уровнях: процессы работали, грамотный человек и сам код писал качественный, и других этому научил. И вот было нанято нечто, что стало тянуть ее в ничем не прикрытый базовый уровень. Очень напоминает рассказы о тупых сыночках-бездельниках, пускающих по миру родителей, прежде хорошо стоявших на ногах (у меня перед глазами полно таких случаев). "Щас в битконы вложусь, все вам отдам"... А если приводить примеры компаний, то посмотрите на Boeing, в 80-е бывшую чуть ли не идеалом инженерной культуры, теперь уже соскользнувшую ниже второго уровня.
И я не говорю о каких-то существенных затратах на рост. В своей жизни я встретил только одного "перфекциониста", т.е. того, который все всегда переделывал и никогда ничего не заканчивал. Все остальное -- это разумная забота о качестве, стремление к стабильности и безопасности. А преждевременная пессимизация никогда никого до добра не доводила.
Студент может жить от стипендии до стипендии, но при этом инвестировать время и силы в образование: не за горами его выход на второй и далее уровни.
В теории. На практике же, 99% таких студентов влачат жалкое существование. В лучшем случае, им может быть повезет, и они станут кем-то вроде автора этой публикации. Но он еще смог адаптироваться к меняющемуся миру. Не каждому это дано.
Мир совсем не так устроен как вы думаете. На 50% в успехе человека (под успехом я в данном случае подразумеваю обладание хотя бы миллионом долларов) - заслуга его родителей, наследственность и связи. На 50% в везении. Хотя это всё может быть названо везением.
Такие вещи как трудолюбие… упорство и таланты, это работает, но не так. Вы можете быть очень талантливым и трудолюбивым. Но свой талант будете употреблять на какие-то идеалистические, ложные цели, которые плохо ложатся на реалии жизненных условий страны в которой вы живете.
Например, у вас может быть IQ 140+ и вы талантливый инженер. Получаете зарплату 150 тысяч. Воображаете что жизнь удалась. На самом же деле вы ничтожество, стоящее почти на самых низких уровнях социальной иерархии.
А сын полковника с IQ 105, когда-то 15 лет назад отучился в школе милиции и уже сам стал подполковником. Он уважаемый человек, он может решать такие проблемы которые вы даже представить не способны, у него много денег, он знает правила игры системы в которой живет. И она его за это вознаграждает. А вы думали, кто ездит на машинах за 20 миллионов рублей?
Пирамида потребностей Маслоу -- она не про объективный успех, а про субъективные ощущения. Диогену и в бочке было норм, а Илону Маску всего мало.
Пример с сыночком полковника -- это пример того, почему я НЕ живу в России. Своих условных 150 тысяч мне хватало для того, чтобы заполнить первые два базовых уровня, но далее я не мог себя почувствовать уважаемым (четвертый уровень) и не мог почувствовать себя частью общества, считающего это нормой (третий). Не то чтобы у меня сейчас заполнены все уровни потребностей, но они уже не связаны с деньгами или отношением окружающих.
Так или иначе, я не понял вашего перехода с идеи конкуренции в бизнесе (с якобы необходимостью при этом жертвовать потребностями высоких уровней) на сыночка полковника.
А через неделю, когда мы успешно всё внедрили, он сам спросил, какие ещё системы требуют доработки.
Йож — птиц гордый: пока не получит хорошего пинка — не за что не полетит!
...а Вы мало, что себя унизили, ещё со своим "техническим долгом" других, грубо говоря, подставили. бизнес - это честность, прога - это радость. не можете этого блюсти - сожалею, но Вам место...
Если принять что статья реклама-то ок, сначала набросили на вентилятор-а дальше уже раздуло.
А так-сейчас работаю разрабом, но ищу что-то более здоровое в плане культуры:
нет документации вообще
комментариев в коде тоже нет
SVN, GIT - что это ? (нет, я то знаю, но вот коллеги...Да и руководству это не нужно)
на тебя сваливают чужой код, с тех долгом еще вполне себе живые разработчики (сами породили ЭТО и не хотят поддерживать- шедевральное отношение ! )
Для себя правда определился: веду и лог файл (что где и когда сделал: у нас по сто программ в месяц выходит), в каждом проекте веду краткую документацию (но насколько позволяет время в таком бешенном темпе),нашел баг или понял где-что надо дописать-сразу напиши в readme в папке с проектом. Хотя бы так, на уровне колхоза :) (изначально хотел дома развернуть Обсидиан с базой знаний, но понял что при зп ниже 50к вкладывать что-то в текущее место работы-суицид).
где-то к середине статьи я подумал, что это была реклама. так и оказалось.
"Я предложил наш обычный подход: сначала документация, детальное проектирование API и архитектуры" - это реально шляпа. не знаю как в Django, на Ruby есть DSL'ки которые по коду (не по тестам) формируют документацию API. пишешь код - и автодока готова. это тоже на любителя, но все же.
"Технический долг: Отсутствие тестов в платежной системе". ну это просто ))). какой же это технический долг? это просто безумие чистой воды. Такая разработка и есть деньги инвесторов на ветер. Непокрытие тестами (фич особо) уже неприемлемо, но когда речь о клиентском сервисе связанным с деньгами и оплатой - ну, просто слов нет. этого просто не может быть. первая же бага, когда саппорту прилетит от одного клиента финансовая проблема с его деньгами - заблокирует все. а если представить, что сервисом пользуются тысячи и прилетит 100 таких багов - да вы просто не разгребете и бизнес просто встанет. вы же не Яндекс, с неограниченными человеко-ресурсами.
PS. в данном случае и я заподозрил, что статья какой-то фейк. не мог никакой СТО даже самый упоротый и никакая компания даже самая упоротая выкатит платежную систему без 100% покрытия тестами. другие участки кода можно меньше покрывать, но не этот.
Так нет никакой проблемы в выборе верной стратегии. Перфекционистам - туда, где вопросы действительно важные (жизни и смерти (медицина, авиастроение и т.д.), на крайняк - финансовый контур банков). А в остальных отраслях - распределение 20/80, т.е. выжимаем 400% эффективности из 100% рабочего ресурса, минус 200% на багфикс и вуаля - 200% эффективности в сухом остатке. Хуже, когда на проект, где логичнее применять 20/80, приходит начальник-перфекционист (ситуация, обратная описанной в статье) - вот тут начинается торможение из-за бюрократии, а потом попытки догонять в авральном режиме. И перфекционистам ничего не докажешь, для них любая мелкая проблемы выглядит равновеликой с реальными проблемами.
Партизанство поможет, если задачу делать неделю, говори две и одну из них рефактори смежные части. Ну или вообще на фига было расписывать типо неделю буду проектировать потом 2 недели кодить, просто говори что суммарно надо 3 недели и всё иди делай как сам считаешь нужным.
Да че там Вы о своих программах * .
А если серъезно то такое происходит и в более ответственных отрослях где вопрос о здоровье и жизни людей. И даже в медецине.
Перфекционист? Готовься остаться без работы