Pull to refresh

Comments 76

Очень все знакомо! Много у нас подобных контор. Только я предпочитаю валить с таких предприятий, чем мириться с этим.
а что такого, с чем нужно «мириться»? это реальность.
Вообще в этой истории все молодцы, и все сделано правильно (без сарказма). А Жанне, как менеджеру надо памятник поставить.
Вот вы задумайтесь и взгляните на картину не со стороны «обиженного» программиста, а объективно: что на выходе?
А на выходе: устойчивая самоподдерживающаяся система с разумным обновлением кадров. За счет молодых энтузиастов ИТ-системы получают должное развитие и постепенно и плавно обновляются с использованием новых технологий, т.е. не застряли в 90-х, но в то же время за счет опытных сотрудников не несутся впереди паровоза за непроверенными новомодностями. Жанна грамотно распределила проекты между ними, все было сделано в срок, ничего не сломано.
Задачи бизнеса решаются. Конечно с привлечением непрофильных сотрудников — это так и должно быть — горизонтальная коммуникация и обмен смежным опытом обязан происходить! Программист не должен сидеть в башне из слоновой кости и думать о вечном. Объективная сложная ситуация с компьютерной грамотностью большинства условных «бухгалтеров» — это то, с чем приходится жить. Задача менеджмента заставить компанию функционировать в заданном окружении, включая имеющийся рынок труда.
И судя по всему, тут это сделано!
Причем и финансово и организационно, объективно в компании все хорошо — премии платятся, причем тому, кто их реально заслужил — нечастое явление в крупных компаниях. Расстояние в иерархии между исполнителем и директором — 2 ступени, да это ж просто сказка какая-то.
Сергей получил бесценный жизненный опыт, а Коля продолжил свое профессиональное развитие в другой компании — уж явно без работы не остался же. А то что на свете одним энтузиастом стало меньше и один прагматиком больше — так это не беда, а естественный процесс развития/взросления человека. Се ля ви.
Нельзя вот так просто взять ипотеку и остаться энтузиастом…
Вот вы задумайтесь и взгляните на картину не со стороны «обиженного» программиста, а объективно: что на выходе?

По-моему, автор именно это и пытался сделать (в чём преуспел) — посмотреть объективно и зрело на ситуацию.
Хорошо написано!

«А потому что у нас так заведено» © анекдот про мартышек.
Неплохо. Даже весьма.
И за бауманку таки приятно.

<irony>
На следующий день после приема Вити hr уже видит задачу найти замену Сереже в течении года.
</irony>

… найти замену не Сереже а Вити.
Ох как же это жизненно! Лучшее из того, что читал. Вы вернули мне мой 2010й!
А почему необходимо противопоставлять технологии требованиям бизнеса?
Художественный приём же.

А вообще — бизнес это вотпрямщас, а технологии — это когда-нибудь потом и еще неизвестно, окупится ли.
Не хочу обидеть автора, рассказ увлекательный, читать интересно. Однако не разделяю восторженных отзывов. Я так понимаю, тут плохой считается компания, которая ломает бедных правильных специалистов и заставляет их работать ради прибыли компании (надо же какие жестокие люди).
Во первых, мне очень слабо верится, что человек без опыта работы начинают сразу переписывать рабочий проект на новую платформу и при этом ничего не сломает.
Во вторых, как-то непонятно, как Сергей пришел от мысли, что он должен работать на благо компании, к тому, чтобы делать работу за бухгалтерию. Логично было начать автоматизировать обезьянью работу и обучать пользователей делать все самостоятельно. При этом (он ведь уже понимал механизм выписывания премий) замерить эффективность сдачи отчетности до и после ввода автоматизации.
В третьих, не совсем понятна компетентность Коли, который воодушевился вчерашним студентом и стал следовать за ним. Мне казалось, что должно быть наоборот: опытные люди направляют новичков. И в итоге Коля вообще уволился, вместо того, чтобы продолжить дело по автоматизации ручной работы.
Может мне кто-нибудь объяснить, в чем скрытый посыл у данного произведения и чем это так цепляет остальных?
А посыл не скрытый :) И цепляет тем, что в какой-то этап своей карьеры большинство специалистов сталкивается с таким бизнесом. Написано емко и хорошо.
За интеграцию 1С и Битрикса, которую ты сделал. Это очень нужное, своевременное и качественное решение. Особенно хорошо, что ты уложился в короткий срок, и не стал противиться, как… Как ты это делал раньше.

В реалиях бизнес как-то лояльнее воспринимает такие вещи, чем объяснения, почему нужно переписывать «фундамент». Долгосрочные перспективы вообще с трудом обычно воспринимаются — гарантий «беды» нет, на текущий момент работает.
При этом (он ведь уже понимал механизм выписывания премий) замерить эффективность сдачи отчетности до и после ввода автоматизации.

А она (эффективность) ниже будет :) Т.к. на обучение уйдет время, на первых порах ошибки будут и т.п. По сравнению с «отлаженным процессом привлечения программиста» поедут сроки. И кто виноват будет, как вы думаете?
А вот из данного рассказа я не понял зачем надо было переписывать фундамент.
Я бы все там поменял. Нет, не так – просто заменил бы Битрикс, переделал сайт. Хотя, это работы на год, не меньше…

То есть он хочет год заниматься переписыванием рабочего функционала, не объясняя риски? Если уж это действительно необходимо, то надо объяснить, что с вероятностью 146% сайт загнется под новогодней нагрузкой и компания потеряет миллиарды монет, но условный молодец Сергей может это предотвратить за 1% от миллиарда монет в течении года (допустим, это его зарплата). Обычно такое бизнес понимает. А если не понимает, то долго не живет.
Т.к. на обучение уйдет время, на первых порах ошибки будут и т.п.

А тут уже условный Сергей должен думать о долгосрочных перспективах и показывать долгосрочные результаты, когда пойдет просить премию.
Если вводить автоматизацию постепенно, а не ломать все сразу к чертям, то сроки могут и не поехать. Вот автоматизировал Сергей какой-нибудь отчет. Возможность делать его вручную поначалу не убирает. Первый месяц сам его формирует автоматически. Потом обучает бухгалтеров и внимательно наблюдает как они это делают. В третий месяц они уже сами будут все делать без его помощи и старую возможность ручной работы для этого отчета можно убирать. После этого переходить к следующему этапу автоматизации. Да, это займет время. Зато не убьет бизнес.
>То есть он хочет год заниматься переписыванием рабочего функционала, не объясняя риски?
Об этом как раз и статья: что Колян, что Сергей, что Виктор — нормальные специалисты. А вот менеджмент у них — говно. Единственная постоянная в этом рассказе — Жанна-управленец. Колян, Сергей, Виктор и те, что после них будут — приходят со светлыми идеями, но сама система управления подразумевает, что выгоднее глазки бухгалтерии за премию строить, чем внедрять новые технологии и эффективные решения.
Мне кажется, специалист должен не только уметь внедрять новые технологии и эффективные решения, но и объяснять эффективность и выгоду этих решений. Иначе получится внедрение новых технологий ради внедрения новых технологий.
Нет, специалист не обязан уметь объяснять. Лучше, чтобы умел, конечно.
А вот Жанна должна была понимать и уметь доносить до начальства.
Если специалист не в состоянии объяснить, зачем надо что-то переписать на новую технологию, то скорее всего он сам этого не понимает. При условии, конечно, адекватного менеджера, которому он это будет объяснять. В данном рассказе Жанна — пример адекватного менеджера.
А вот Жанна должна была понимать и уметь доносить до начальства.

Зачем? Никто не ожидает, что команда Жанны будет звезды с неба хватать. Если при помощи программистов, делающих манки джоб проблемы стабильно и прогнозируемо решаются, то это лучше, чем начать Большое Переписывание, тем самым сыграв в рулетку, что пусть даже с вероятностью 70% выигрыша (и 30% вероятностью заблокировать бизнес соответственно).
На самом деле это главный вопрос.
Бизнес считает, что «команда Жанны» нужна только для решения текущих проблем или, возможно затрачивая дополнительные усилия, будет готова и обеспечит расширение и изменение бизнеса?
Бизнес считает, что «команда Жанны» нужна только для решения текущих проблем или, возможно затрачивая дополнительные усилия, будет готова и обеспечит расширение и изменение бизнеса?

Наоборот, я вижу, что часто бизнес финансирует говноподелки. Пишутся годами забагованные велосипеды, которые, какбы, идеально подходят под уникальный бизнес-процесс. Разумеется, стандартные решения, конечно же, не подойдут. Ведь зачем хеду бизнес-юнита менять процесс, когда программисты все напишут. Поменять процесс и получить убыток — отвечать самому. Сохранить процесс, но получить убыток за счет багов — можно свалить все на программистов.

По факту, именно удальцы с горящими глазами, произносящими что-то вроде
— Там в код надо смотреть, в метаданные, которых нет, в корявую СУБД, не подходящую для реальных крупных проектов. Я бы все там поменял. Нет, не так – просто заменил бы Битрикс, переделал сайт. Хотя, это работы на год, не меньше…
тормозят бизнес. Потому, что готовые решения вроде битрикса при всех своих недостатках и устаревшести имеют поддержку, пул готовых специалистов на рынке труда и, самое главное, команду, которая нивелирует бас-фактор. А вот самописные решения (особенно те, автор которых ушел, пошел на повышение, или просто потух) представляют из себя черные ящики.

PS: и да, если мы говорим о компании, основная компетенция которой — IT, или о компании, которая готова содержать R&D, превышающее по костам содержание всей компании-поставщика коробочного ПО, то расклад будет другой. Но это уже другая история.
Потому, что готовые решения вроде битрикса при всех своих недостатках и устаревшести имеют поддержку, пул готовых специалистов на рынке труда и, самое главное, команду, которая нивелирует бас-фактор. А вот самописные решения (особенно те, автор которых ушел, пошел на повышение, или просто потух) представляют из себя черные ящики.

Вот именно в этих случаях когда типовые решения на подходят, но при этом не охота городить велосипед и существуют фреймворки, причем для всех более менее развитых языков. Которые позволяют взять типовые решения определенных проблем (бд, логи, валидация, админка) а для конкретной уникальной бизнес-задачи написать кейс который полностью удовлетворит самые смелые бредни заказчика.


В этом случае бизнес-велосипед изолирован от стандартных решений и новому человеку придется только понять только эту нестандартную часть — остальное уже есть в доках к фреймворку и учиться на раз-два. Тем более что компоненты фреймворках даже на разных языках похожи — тот же DI, та-же ORM тот же логер, тот же Роутинг и все остальное.

Полностью согласен в вашим мнением. Это прямая работа начальства (в данном случае Жанны) «допросить» програмиста, чтобы толково донести до своего начальства причины изменения/улучшения.

На мой взгляд, если хочешь максимально донести до начальства суть и перспективы улучшения, поставь себя на место менежера и задай себе теже вопросы. Иными словами нужно понять кто заинтересованные стороны (staсkholders) для данного решения и что для них является приоритеным. Есть еще много других вопросов, но я думаю я смог донести суть.

Ответя себе (и позже менежеру на эти вопросы) вы предоставите ему/ей «внятные» аргументы для их начальства. (не забываем что не все менежеры одинакого «тянут» в технологиях.) Так как начальство будет оперировать именно этими терминами, а не технологическими.

Как ни крути, но сроки, бюджет, риски и ресурсы будут более релевантны и понятны для начальства.

Во первых, мне очень слабо верится, что человек без опыта работы начинают сразу переписывать рабочий проект на новую платформу и при этом ничего не сломает.

В этом и есть смысл — сломать. Именно так перестраиваются системы и никак иначе. Ты делаешь один кусок правильно, из-за этого ломается другой кусок — и вот ты уже делаешь второй кусок правильно. Потом вынужденно делаешь третий кусок, который сам же и сломал вторым. Я так перестраивал огромные системы за недели. Писать с нуля в сто миллионов раз проще и быстрее, чем допиливать гавнище.
Вы всегда будете встречаться с фразами «там все так сложно! ты не понимаешь, куда лезешь!». Буллшит! Сложны там только костыли, которые подпирают костыли для костылей. Именно их и боятся сломать. А внутри реальное зернышко.
Смысл не сломать. Смысл — чтобы все работало и приносило деньги. Иногда действительно выгодно переписывать все с нуля, но делать это надо не по прихоти программиста (нас ведь хлебом не корми, дай переписать что-нибудь), а потому что это будет выгоднее, чем поддержка старого кода.
Именно так перестраиваются системы и никак иначе.

Если вы не сталкивались со случаями поэтапного переписывания системы, это еще не значит, что такого вообще не бывает.
Смысл не сломать. Смысл — чтобы все работало и приносило деньги.

Я говорил про смысл закрытия технического долга, а не про смысл, как его видит менеджер. Потому что «работает и приносит деньги» — это настолько абстрактно, что не несет никакой смысловой нагрузки. Я сейчас в проекте, где деплоймент на тестовую среду идет примерно 2-3 месяца. Но считается, что все работает (если все сделают свою работу) и приносит деньги. В статье выше все, как раз, работает и приносит деньги.

У вас мысль так хорошо склеилась, потому что вы восприняли как легкий рефакторинг то, что является звериным техническим долгом. Существует черта, за которой рефакторинг вам уже сделать не дадут. Там, за этой чертой, вы будете ломать уже не код, а людей. И в такой момент всегда оптимальнее делать блиц-криг, потому что ни одна психика не выдержит противостояние одинокого солдата огромной системе, перемалывающей вот таких вот сергеев.

Если вы не сталкивались со случаями поэтапного переписывания системы, это еще не значит, что такого вообще не бывает.

Это моя профессия вот уже много лет. Я видел все. Поверьте, именно все.
Выделить полтора землекопа, которые будут заниматься нормализацией базы, и только ей. Оценку их работы проводить с аутсорса, чтобы не было соблазна использовать их в общих авралах отдела. Нет, использовать конечно, но слегка, и именно в авралах а не в работе за бухов.
Да, нормализация поверх текущей. Долнительные поля, которые пока не используются. Дополнительные отчеты, находящие дубли (которые в текущем раздрае некритичны) и т.п.
Потом те же полтора землекопа постепенно сдвигают родную структуру в сторону «храним нормализованно, но отображаем через врапер чтобы старый апи работал». Ловим проблемы реального бизнеса, несостыковки.
Параллельно пишем новую структуру, новый клиентский код.
Начинаем пилотное внедрение где часть функций в новой платформе, а старое в старой. Обязательно не забыть плюшки для рядовых сотрудников, чтобы они увидели что им удобнее работать по новому. Желательно «ненужных» не увольнять, а придумать как они принесут дополнительную прибыль, вместо убытков.
Еще на этапе нормализации на каждом шаге делаем кучу отчетов чтобы находить проблемные места и показывать ТОПам реальную прибыль/экономию. Аккуратно обойдя все те места которые если не обойдешь, то саботаж убьет весь проект. (Никогда не задумывались почему бизнес-аналитики обычно таскают большой физический диктофон? Его удобно демонстративно включать и выключать… «не для протокола»).
И тогда да. Можно говорить о техническом долге.
Не не не. В жизни такого нет. Вы не менеджер, чтобы что-то выделать. Выделать вам ничего никто не будет. Слушать аргументацию с цифрами — тоже.

Точнее не так. А так: когда вы будете говорить, что вы предлагаете, ваши цифры послушают. И скажут, что столько времени у них нет, ведь дедлайн завтра. Но старый путь они не считают. Ведь он разделен на мелкие кусочки, самый первый из которых будет до делайна (его конечно не будет — продлят, так как не завелось, но сегодня он будет до дедлайна).
Это система двойных стандартов, где считают только то, что выгодно считать, а что не выгодно — то не считают вообще или разбивают на мелкие куски, считая первый.

Все ваши посылы основываются на том, что на той стороне переговоров рациональные люди, которых можно убедить доводами и аргументами. Этих людей там нет. Там ад, тупость и серпентариум.

Вы точно поняли посыл статьи? Потому что она об этом.
Откуда вы знаете, что в жизни такого не бывает? Ах да:
Я видел все. Поверьте, именно все.

Это очень интересно, ведь я ни разу не видел людей, которые видели все. По вашей логике получается, что таких людей в жизни не бывает. А вот вы оказывается есть:)
Я глубоко знаком с десятком основных менталитетов в ИТ области (и жил в большинстве этих стран). Поверьте, не надо видеть все, чтобы точно знать, что видел все паттерны и ничего нового уже не увидишь.
Меняйте почаще работу и тоже заметите, что люди одинаковые везде, в рамках своей культуры. Вы сможете даже предсказывать будущее!
Возможно в какой-то момент произошло недопонимание и мы сейчас говорим о разных вещах. На всякий случай уточню, что я спорю против утверждения «проект с плохо написанным кодом необходимо переписывать с нуля; переписать его постепенно не получится» — это не цитата, это то, как я понимаю вашу позицию (возможно, ошибочно).
Вы говорите, что многое видели, но такого не видели — значит этого нет. Я не говорю, что я видел много, но я видел, что такое успешно делается — значит это есть. С точки зрения формальной логики я прав:)
То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле)

Вы точно ко мне обращаетесь?)
Я здесь говорю лишь о том, что вариант «все сломать, а потом построить свой новый прекрасный мир» ничуть не лучше чем загнивать в старом болоте.
А так то всякое в жизни бывает.
Я и на месте Сережи был, и на месте Коли, и на месте Жанны, и на месте генерала, и не одно внедрение видел, и пару крупных сам делал. Вот по разному бывает. И не помню ни одного случая когда бы «сломать а там построим лучше» приводило бы к хорошему результату. Обычно хорошо получается только первая часть плана.
Вы мажете с ответами. Я этого не писал.

И не помню ни одного случая когда бы «сломать а там построим лучше» приводило бы к хорошему результату

Меня отослали в Индию на месяц. Я вернулся домой — уволили 402 человка из Convergys. Количество релизов от 1 в два месяца поднялось до 4 в сутки.
И таких примеров из моей практики полно. В данный момент я тоже самое делаю в Сити. И я никогда не работаю больше месяца-двух на одном проекте.
UFO just landed and posted this here
Почему хуже? Манагеры правы.
UFO just landed and posted this here
в своё свободное время, по выходным и вечерам сделал подобную замену

Он это согласовал? Нет.
на более подходящих для этого технологиях

А кто решает их подходящесть? Человек который ради фана свои выходные профукал на работу которую его не просили делать, но по его мнению она правильно сделанная?
потому что в этих самых технологиях не так много специалистов

Это я сказал? Или вы сказали? Их реально не много? Насколько существенно упадет bus-factor? Кто-то считал? А эти самые специалисты которые есть, но в других отделах, они там не нужны да? А увольнение тех на кого нужно будет заменять (текущая технология) безболезненно? А переобучение персонала и вообще внедрение (у любой корпоративной ИС — код это максимум, именно МАКСИМУМ 10% от всего проекта), документация, неизбежные швы интеграции и замены… это все считалось? Согласовывалось?
Или таки да, ради фана набросал, и обиделся что не похвалили?
поэтому ему предложили либо переписывать на чём-то более традиционном, либо иди нафиг

Раньше догадаться об этом было нельзя?
Да, Proof of concept есть, но на этом всё.
На моей практике дважды крупные проекты гибли от того что bus factor был слишком мал, сразу после «а теперь мы перейдем на новую, супер-крутую технологию которая намного лучше подходит данной задаче».
Дважды.
А тут еще и такой фактор что манагеры не могут оценить что под капотом. Насколько объективно его быстрое решение можно будет поддерживать когда он перегорит, и ему будет неинтересно. Качество кода, документация, архитектурные решения. и т.п.

Может быть. Если бы он подумал заранее. Согласовал бы. Использовал компромисный пул технологий… может быть. Но не вот так «я тут на выходных написал что-то, вы должны оценить».
По сути чувак обиделся что какие-то манагеры приняли решение по технологиям, не понимая в технологиях. При этом он возмущен что манагеры судят о технологиях, но его не смущает что он судит работу манагеров не понимая в ней так же как они не понимают в технологиях. Просто шикарно.
UFO just landed and posted this here
Двойные стандарты и «непосредственный руководитель был в курсе» — это да, аргументация. Но ее не было в изначальном комментарии на который я писал «манагеры правы».
А так то с учетом деталей которые уже озвучили могу сказать только что ничего сказать не могу. Не надо было давать добро, если не отслеживаешь стек технологий, не надо было соглашаться на «ну попробуй в свободное время» (что уже попахивает). А кто больше накосячил — понять сложно.
Меж тем 1С v7.7 до сих пор существует.
Я очень хорошо помню, как одно время работал манагером в одной корпорации.
Основное направление было расходники и прочая химия от одного западного бренда, чье название было у корпорации в названии (по лицензии), но и тендеры на оборудование и прочие особо выгодные вещи тоже были, и не на последних местах.
Помню как позвонил кто-то. Секретарь назвал вслух название организации, и весь оупенспейс" начал активно махать руками, мол только не на меня. Ну понятное дело я сказал чтобы переключили на меня (хотя это и совсем не моя задача была, но «человек же ждет...»). В общем это была какая-то больница. Им полгода назад поставили оборудование по тендеру. И они уже несколько месяцев не могли получить весь пакет документов. Их главбух (а это была она) очень переживала (мягко, очень мягко говорю), ведь у них пришла проверка из КРУ, а документов нет.
Я ее конечно заверил что сделаю все возможное, и все такое. Она извинилась за тон и т.п.
Нет, я сделал все возможное. В принципе какую бы маленькую должность я не занимал, у меня никогда не было психологических проблем пойти «на ковер» к генералу.
Но проблема была неразрешимой.
Начальник АСУ корпорации был племянником генеральши (имевшей значительный пакет акций) и он решил что старую версию 1с нужно заменить на новую. Ведь уже вышла 8.0 бета…
На момент моего увольнения (через месяц после событий) документов еще не было.
UFO just landed and posted this here
как-то непонятно, как Сергей пришел от мысли, что он должен работать на благо компании, к тому, чтобы делать работу за бухгалтерию. Логично было начать автоматизировать обезьянью работу и обучать пользователей делать все самостоятельно. При этом (он ведь уже понимал механизм выписывания премий) замерить эффективность сдачи отчетности до и после ввода автоматизации.
«Если админ(программист) не бегает по отделам в поте лица, значит он не работает»(с)
К сожалению такова логика многих «руководителей»…

И почему, когда я читал пролог, я точно знал, что будет в эпилоге?

Кажется, вот момент, когда Сергей профукал своё будущее как профессионала (и, возможно, как будущего управленца):


— Выгодно, сложно спорить. Но нужно понимать сроки и стоимость этого проекта. На словах все красиво звучит, но пока это только слова. Если я сейчас пойду к генеральному, предложу этот проект, то мы уже не сможем его не выполнить. Ты уверен, что учел все нюансы реальной жизни? Подводные камни, трудности перехода, саботаж при внедрении? Те же операторы и их начальник — как отнесутся к внедрению? Их силами ведь твой MDM заполнять. Насколько качественно они будут наполнять систему, которая их заменит?

— Ну, я не думал об этом, если честно. Но за технологии я готов поручиться, потому что видел исходники и их реальную работу. Та же CouchDB, с автоматической репликацией…

Как профессионал, он мог взять таймаут на анализ рисков и просчет прогнозного PnL по таким проектам, подготовить презентацию для гендира (или посчитав отказаться от проекта, но обоснованно). Если бы он еще и взял на себя координацию, то мог стать хорошим PM. А так пусть дальше месяца с бухами закрывает и номенклатуру руками перегружает.

Он не профессионал, а студент с меньше года стажа.
Я считаю, что не было в тексте ни одного момента где бы Сергей получил бы повышение. И не важно, какие там технологии и не важно какие там будут условные «сергеи» с горящими глазами или нет, испорченные они или нет. Один результат — никаких повышений никаким сергеям в таких компаниях не видать. Какие P&L? О чем вы говорите, история ведь повторила итерацию зимой, а что у нас зимой? — Годовой отчет с закрытием финансового года.
Могу предположить что запарка с закрытием периода, со сведением несводимого и проводками у финансового отдела (бухгалтеров) была из-за того, что кто-то в компании мутит с товарными позициями по черному. И уверен что делается это группой лиц, и даже почему-то не буду удивлен, что вот эта вот дама, условная жанна с крамольной «задачей реального бизнеса», всего лишь ширма, за которой таится яма безисходности в которой тонет и засасывает. Что сергей хотел оптимизировать? Колян-то небось на этот момент уже был в курсе про мифические остатки на складе и левые проводки с логистикой или сетями?
Как мы знаем прописную истину, сотрудники уходят не из компании, сотрудники всегда уходят от других людей. Вот здесь кроется все самое-самое главное. От других людей уходят. Вот в этом направлении я бы и копал — начиная с завхоза, старшего менеджера логистики и «продажников». Скорее всего именно от этого списка убегали эти николаи и сергеи, а не от условных битриксов или «ужасного» кода.
Сергей мог бы получить повышение (стоп, а что такое повышение вот этого Сергея? На таких компаниях это всегда — слив условной Жанны.) если бы он тихо начал бы исследовать предметно источники всей этот текучки, и главное(!), а это всегда ключ к повышению (тьфу) решению, выяснил причины по которым конкретные люди не увольняются. То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле), где он бы во всех красках рассказал по каким реальным причинам дяди и тети сводят несводимый баланс и рисуют упомянутый выше P&L репорт. Вот тогда, бы история была бы намного интереснее.
То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле), где он бы во всех красках рассказал по каким реальным причинам дяди и тети сводят несводимый баланс и рисуют упомянутый выше P&L репорт. Вот тогда, бы история была бы намного интереснее.

— Держи карман шире… Мне премия… нужна, у меня ипотека.
Пусть эта фраза не вводит вас в заблуждение, в таких компаниях квартальная премия платится за выполнение ранее поставленного плана, а сводят они(по сути заинтересованные люди) баланс настолько красиво, что как правило, этот самый план всегда выходит выполнен (сводится в ноль, кому как привычнее слышать).
Эх, жаль, название конторы-то не сказали, а то по некоторым признакам там еще есть и производственные отделы, и даже конструкторский отдел ) Это ведь намного-намного увлекательнее могло быть начало, типа «в первый день сотворения Компании был поставлен турникет, и первые люди сразу начали ходить через него, а потом вырасли стены конструкторского отдела...»
То вот тогда бы, можно было бы писать докладную записку на главного (только на самого главного, владельца бизнеса, а не кантри-менеджера который вполне может быть и в доле)

Бугага! И еще трижды «Ха» в придачу!
Если предприятие достаточно времени существует, то в подавляющем большинстве случаев всё болото исходит именно от «самого главного который принимает решения».
Жанну и главбуха кто-то нанимал. Генерал, или совет директоров. Не суть. Самого генерала кто-то нанимал. Их кто-то продвигал. Других задвигал. Кто-то нанимал кадровиков. Кто-то выплачивал им премии и выписывал штрафы. Кто-то назначал коммерческого, кто-то утверждал его стратегические планы.
И во всем этом была та или иная мотивация.
Это могло быть «да пофиг». Могло быть «во всем этом я не сильно разбираюсь, деньги приносит, ну нафиг, вдруг поломаю». Бывает " ну блин, я же его генерального со школы знаю, Главбух моя любовница а Жанна лучшая подруга жены". Не важно. Важно то, что «всё это» приходит именно от «самого главного, главнее генерала». Всегда.
Ну а если там много акционеров, то все равно примерно та же картина, только с учетом балансов интересов разных сторон.
Мы о разных вещах говорим, вы про типичный российский крысятник (до 100 человек), я же про либо региональный филиал крупной российской корпорации, либо про дочернюю компанию иностранной компании в РФ (авто/кондитерка/нефть). В типичном российском крысятнике делать нечего даже на этапе собеседования(но это я отвлекся), и я почему-то думаю, что «сергей» ну никак не мог решить со своей ипотекой, видя ставку крысятника, во главе крысятника естественно король крыс из «Щелкунчика».
Есть старый бородатый анекдот: «Рабинович, ну купи ты хоть один лотерейный билет». Я не говорю, что у Сергея бы всё получилось с его инициативами, что его обязательно повысят. Но он же «лотерейный билет не купил». Да, очень часто нужно свои решения в бизнесе обосновывать и показывать-доказывать, что решения верные, а вы, как исполнитель, подходите для их реализации.

Переформулирую. Я (не абстрактный виртуальный Сергей, а я) в этой ситуации первым делом поинтересовался бы у руководителя, могу ли я помочь обосновать свои решения и проработать их. Составить список возможных слабых мест решения, может какой-нибудь простенький SWOT накидать.
Да, часто убедить в своей правоте не получается (кто-то сдастся на первом отказе, кто-то на сто первом, а кто-то вовремя поймет, что лучше доказывать другим начальникам :) ). Да, часто это не только, и не столько техническое обоснование. Но если ты сдался, если решил «ну что я тут самый умный что ли», то это и есть то самое «профукал своё будущее как профессионала».

У меня были эпизоды, когда мне выгоднее было поступить не вполне профессионально, например, когда я, как консультант, должен был посоветовать «наше» решение, но оно клиенту не подходило (впарить моей квалификации бы хватило). Я стараюсь в этих случаях не разменивать свой профессионализм на сиюминутную выгоду. В начале карьеры это, кстати, еще важнее.
Из этой компании, кстати, я очень корректно (не хлопая дверью, найдя замену, передав дела) ушел, как только понял, что этот конфликт между текущими показателями и моим мнением на этой позиции — системный, а не разовый. С этой организацией впоследствии сотрудничал, как клиент.

Я не готов по обрывкам информации в этом рассказе делать такие глубокие выводы про то, что творится в описанной организации, мутит ли там кто-то с остатками, кто виноват, права ли Жанна и так далее. Я всего лишь хочу сказать, что если Сергей так легко сдался, то именно этим он себе помешал. Если на этом заводе всё так плохо, то надо валить, а не становиться «1С-нком закрывателем месяца».
— Да там все не так, в основе, в фундаменте.

Мы программируем на языках, где даже в стандартной библиотеке есть странности (почему в питоне в logging все названо camel-case-ом?). Мы пишем код в неудобных навороченных глючащих монстрах (привет вам, IDEA и VS). Мы пользуемся синтаксисом, который без поллитра не разберешь (привет и вам, шаблоны C++). Так почему же мы не можем пережить неидеальности фундамента софта, который разрабатываем? Вообще, по опыту, если человек говорит о «фундаментальной неверности» всего, а не перечисляет конкретные проблемы (и, желательно, сразу предлагает конкретное решение), то это либо инфантилизм, либо вкусовщина. А ни то, ни другое не должно быть свойственно профессионалу.

Ну вот Идею ты зря назвал "неудобной". Прекрасный инструмент.

После VS (2017) субъективно кажется очень тугой и неповоротливой.
я же говорю — субъективно. Например, время запуска и загрузка примерно одинаковых по размеру проектов.
Многим людям в России, и бизнесменам в частности, не свойственно думать на перспективу. «Пока гром не грянет...»-этой пословице не одна сотня лет наверное. Сталкивался с самым настоящим идиотизмом: система видеонаблюдения, ломается диск, выписывается счёт, ставится в план, оплачивается, меняется. Всё это время-1-2 недели(!)-видеонаблюдение не работает. А как насчёт купить диск и положить на полочку чтобы в случае поломки менять сразу? Нет, это нам не надо. Работаем по факту: сломалось-покупаем. Возникла проблема-решаем. Есть на это конечно и объективные причины-быстро и неожиданно меняющееся законодательство, риски закрытия проверкой росгосстрахбабахкирдыкнадзора, отжатия пацанами в погонах и т.д. никак не способствуют желанию думать о будущем. Но первопричина всё-таки в пословице. Ведь законодатели и силовики живут по тем же принципам.
не слушай этого старого коня. Борозды он, конечно, не испортит, но и целины не поднимет.

В мэмориз :-D Кажется, это нужно кое-кому сказать на работе.
Рассказ начинается с середины.
Началось все так:
— Сереееж… Ну сколько мы еще будем скитаться по съемным квартирам? Давай возьмем ипотеку!
[sarcasm]
… вот так и становятся одинесниками…
[/sarcasm]
Просто мне попадались несколько программистов 1С, которые по образованию и не ИТ-шники, но в 1С пошли потому что там тогда «было тепло и платили».

По моей щеке течет скупая слеза ...

Очень напомнило первую работу. Как я рад, что свалил еще «летом»)
Жизненно.
Я сам нахожусь на стадии сотворения лыж и ретроспективы — как же Серёже стоило поступать.

Надо работать над Soft Skills — паниковать и кричать «нам всем хана в течении пол года» не стоит.

Обосновать что при таком подходе будет просто уходить куча человеческих ресурсов на поддержку. Да и сами ресурсы соберут монатки и уйдут.

Вести диалог с бизнесом которому действительно надо побыстрее результат. Находить компромисс и понимать последствия.

Что делать с Колянами из соседней комманды которые быстренько наклепали свой код а получили кучу похвал а тот кому всё это дело надо уже интегрировать дальше в ужасе рвёт волосы на голове???

Ведь Коля здесь уже 10 лет, он то знает что он делает а ты разслабся, всё работает, ну бывают сбои не без этого

Soft skills здесь — компетенция Жанны, я так понимаю. И она вполне успешно справляется.
Простите за некропост, но встретил старую картинку, и вспомнил что тут явно не хватает КДПВ.
image
Картинка не подойдёт, т.к. рассказ ни разу не сатирический. В нём речь идёт поддержании баланса здравого прагматизма и столь же здравого идеализма.
Жираф безусловно был не прав, но как известно виновен не жираф, и баланс тут не соблюден от слова совсем. Техническим долгом нужно управлять, как и финансовым. Реструктуризировать, гасить тело а не только проценты, не брать новый технический долг, не погасив старый… А не так как тут — «платежи» посильны, и ладно. Фактически весь «доход» ИТ-отдела (экспертиза сотрудников в условны стажорочасах, считая час старожила как Х часов стажера) уходит на выплату процентов по техническому долгу и при этом гасится не всё, поскольку долг растет.
Сережа да, идеалист (был), неверно организовывал, преподносил, но… не жираф виновен, а тот кто построил работу так, что он из разраба стал пожарным, тушащим пожары.
Если бы в конце Сережа не целый день провел в бухгалтерии а только полтора часа, принеся от главбуха весточку чтобы Жанна писала «подання» (представление?) на премию для Коли и Сережи — Сереже за помощь с остаточными пожарами, Коле за то что молодец, оптимизировал и внедрил автоматизацию и теперь не день а полтора часа на это уходит. Тогда да, баланс был бы.
ПС: в целом я согласен что статья про баланс, что описано очень хорошо и все такое. И даже с тем что в КДПВ ее не стоит ставить согласен. Правда по другой причине (не желательно совсем уж интригу убивать в начале). Я только не согласен о том что баланс здесь был.
явно это не выражено, да это и не важно.
тут еще про человеческий фактор
Рассказ прекрасный во всех отношениях. Забавляет бурная дискуссия в комментариях — людей цепляет; хорошая литература должна цеплять.
UFO just landed and posted this here
Sign up to leave a comment.

Articles