Comments 214
Интересная тут собралась коллекция комментариев. Автор прямо и честно пишет, что предлагает субъективный дартаньявоский взгляд, но куча народа напихивает ему за "субъективизм", пишет, что надо выслушать обе стороны, и тут же, не отходя от кассы, додумывает, как оно всё было на самом деле.
Мне особенно понравились претензии, что автор "не умеет делегировать", и что "бизнесу нужны фичи, а не чистый код". Но каждый, кто в своей жизни сталкивался с корпоративным булшитом, знает одну простую вещь: бизнес просто не знает, какие фичи ему нужны. Таков закон жизни и это не из-за того, что там все дураки или какие-то плохие люди, просто на это есть ряд объективных причин. И DDD Эванса в лучшей своей части посвящена вопросу изучения бизнес-процессов разработкой совместно с бизнесом и дистилляции понимания этих процессов в явно определённых моделях, правилах и ограничениях. Т.е. это работа продукт-овнера, продукт-менеджера, аналитика и тим-лида понять действительную потребность бизнеса и найти кратчайший путь к её решению. Отсюда и возникает то самое "нет" тимлида, если это хороший тимлид, потому что бизнес часто приходит с хотелками вида "хочу кнопку в табличке на форме", а реальную потребность бизнеса можно закрыть иначе, лучше и дешевле, но для этого на каком-то этапе должен найтись человек со словом "нет".
А вопрос, кто станет этим "мистером нет" напрямую связан с "искусством делегирования". Потому что говорить это "нет" и предлагать более лучшие решения в первую очередь должен продукт-овнер, продукт-менеджер, бизнес-аналитики и только потом тим-лид. Но чем выше позиция к "начальству", тем сильнее у людей развита гибкость позвоночника и все эти важные для успеха продукта люди превращаются в обыкновенных "передастов". Бизнес хочет кнопку - Вася, сделай кнопку. Вот оно - искусство делегирования. Манагер "делегируя" задачу разработке и свою харизму перед бизнесом не портит и себе мыслями голову не нагружает. О сложных вещах пусть разработка думает, обязанность думать и разбираться в сложных вещах менеджер "делегировал" вниз по стеку.
И тут вопрос, кто окажется тем "Васей", на котором остановится эта цепочка делегирования. Часто таким человеком становится тимлид, который знает, что "копать" всё равно ему, поэтому он не поленится "думать" прежде чем взяться за лопату. Такой тимлид прослывёт токсичным душнилой, зато его команда не будет из спринта в спринт закапывать и откапывать стюардессу. Впрочем, не редка ситуация, когда тимлид сам овладел "искусством делегирования". Тогда он встроится в линейку начальников, с которыми бизнесу приятно общаться, а тащить работу будет пара сеньоров. Такое тоже случается сплошь и рядом, люди быстро учатся искусству пофигизма.
Соседняя команда была хитрее: спагетти‑код, ни единого комментария, совершенно невероятные проблемы после минимальных изменений кода. Они готовили себе почву быть незаменимыми сотрудниками.
Вот с этого момента я перестал верить в адекватность суждений благородного дона. И даже дело не в спагетти коде, а в «раскрытии» автором коварнейшего заговора.
Между тайным смыслом и некомпетентностью, чаще всего дело в некомпетентности. Автор сиял на фоне второй команды, а в своем сиянии не заметил как его сожрали. Это фигово и обидно - да, автору не хватило софтскилов, чтобы Зиночку на свою сторону затянуть - может быть. Не повезло с организацией - 100% (судя по формату увольнения без причин (со слов автора)).
В АСУТП, да и в реальном секторе в целом, существуют костыли, которыми некоторые бабаи подперли развалины процессов еще десятки лет назад. Даже после наступления пенсионного возраста они работают, просто потому что за костыль шарит только он - мегадед. Это тайный замысел или некомпетентность? Мне кажется - это что-то третье или четвертое. Как вариант - недостаточная финансовая мотивация. Возможно и тут в команде "зиночки" так и было, как вариант, опять же.
Это здравый подход. Не надо обвинять мегадеда что он специально так сделал. Наверняка и наверх ходил, и пытался проблему обрисовать. Но вовремя ПОНЯЛ: Если кто-то наверху не хочет затруднять себя решением проблемы, то и он НЕ ОБЯЗАН!
К мегадеду претензий ноль. И в целом ваш тезис на 100% в точку. Как я и писал выше, (опять же, как пример) если бы была достаточная мотивация, в т.ч. финансовая, то и без удара сверху костыль бы мог обрасти хотябы блокнотиком с описанием)))
Жованый крот! Ощутил себя мегадедом! - лет 10 назад на одном мясокомбинате, когда руководство решило вести строгий учёт обедов сотрудников, набросал по-быстрому систему учёта посещения столовой, на php+pgsql+1С+VC+какая-то некромансия+... как и на каком азарте делал - аж сам забыл... и вот пару месяцев назад звонит мне оттуда админ со словами "слушай, у нас тут ставка за обед поменялась...". Блин! Костыли неискоренимы!
я про это и говорю: часто внешний наблюдатель не может понять истинные причины некоторых вещей.
Плюсую. Я работал в "около" финтех проекте, где пара мега дедов писали код в одну строчку. Да-да, навыки ещё со времён перфокарт. В таком коде без рефакторинга не разберешься.
А перед тем, как я ушел оттуда, один дед по секрету намекнул: "у меня скоро пенсия, а вас, молодых и горячих, всё больше. Я разработал это, и смогу поддерживать только я, поэтому до пенсии тут доработаю. Меня вряд-ли смогут кем-то заменить".
Дал такой совет мне на будущее, так сказать. В чем-то он прав. Бизнесу нужна безболезненная заменяемость исполнителей, а рядовому сотруднику, особенно старшего поколения - гарантия в завтрашнем дне.
Все достаточно просто. Когда развертывали АСУ ТП толком не понимали объемов работ и выходной результат, делали по хотелкам заказчика. Все были молодые и зеленые, а на объект поехали самые бравые. Когда АСУ ТП мало мальски задышало стало обрастать новыми хотелками и задачами, заодно из каждой дыры полезли проблемы, которые не закладывали на этапе проектирования, проблемы стали затыкать как могли, пока не пришли в идеологический тупик, но тут кто-то придумал мега-костыль, который работает уже долгие годы.
То чувство, когда понимаешь, что сам становишься этим самым мегадедом
Теперь ты дракон
Из отрывочных фактов и мыслей в статье общая картина не складывается совершенно. Я правильно понял: суть истории в том, что автор попал куда-то довольно важной шишкой, хорошо работал (по его мнению), но начал открыто рыпаться на других важных шишек (конечно же, не таких умных как автор), которые работали там гораздо дольше и имели больший авторитет, с закономерным итогом? Если так, то эта история стара, как мир.
обычный тимлид, не важная шишка. История про то, как я проиграл в корпоративных играх, потому как не умел в них играть и считал что результат и прозрачность всегда говорят сами за себя.
я получил предложение на пару ступеней выше — набрать команду с нуля и реализовать проект для клиентов с нуля в другом большом банке в рамках глобальной трансформации
Ну, звучит, как важная шишка.
Результат и прозрачность, несомненно, важны. Не менее важно понимать, чего от тебя ждут. Никакого умения играть в корпоративные игры для этого не требуется.
Например, когда в устоявшуюся команду кого-то нанимают бесконечные таски пилить, он хорошо справляется, но затем начинает всем говорить, что всё неправильно и надо переделать, а всех причастных разогнать, это будет выглядеть максимально странно. "Алло, мы тебя наняли винтиком в машину, а не революцию совершать!"
Не было у тебя прозрачности и межкомандное взаимодействие ты провалил. Иначе, не было бы "Зиночка тут весь твой код пишет", "моя команда вдвое меньше при той же продуктивности", "Зиночка сказала, что ты очень нехороший человек и вообще токсичный, портишь нам атмосферу в трайбе". Последний момент вообще не раскрыт.
Это субъективная точка зрения на реальную ситуацию, где я - Д’Артаньян, а все остальные - редиски.
Раз так, то получай критику.
Читаю и удивляюсь: какие вы тут все проницательные!
Согласен с предыдущим комментарием. Вы просто не встречали достаточно мерзких интригоплетов, когда любое ваше действие оборачивают против вас. И хуже всего, когда при этом ваше же руководство или уже ангажировано не в вашу пользу или ему просто пофиг кто там победит в этих жалких интрижках, т к нет разницы для него кого увольнять. (А судя по тому, что руководство не хотело брать ответственность за провалы на себя, а хотело подставлять подчиненных, так оно и было) Это значит для этого конкретного руководителя вы не ценны и правильным решением было бы либо перейти к другому если это возможно, либо уволиться самому в самый интересный момент. Можно ещё начать отвечать тем же - поиграть в интрижки, если есть такой "софтскил", но по-моему ничего полезного кроме развития именно этого "софтскила" это не принесет. А отношения с другими коллегами может и испортить. Так что на земле просто существуют организации состоящие из таких Зиночек почти целиком, пока наверху в управлении не появляется Геракл, способный и желающий эти конюшни чистить, либо пока эта организация как больной динозавр не падает под весом собственной неуклюжести и некчемности. Больше такого в гос.секторе, но коммерческие монополии, к которым несомненно относятся и крупные банки, ничуть не отстают...
Классическая ситуация.
На руднике уходил на пенсию зам. начальника рудника по производству (третий человек на руднике сверху). Выбор для текущего начальника рудника из двух кандидатов:
1) Толковый, но не лояльный. В кабинет начальника поболтать не ходит.
2) Лояльный но по профессиональным качествам хуже, с начальником болтает.
Начальнику оба кандидата одинаково не нравились, что несговорчивый профессионал, что лояльный дилетант, чем кончилось дело?
Пришёл новый начальник рудника (старый уволился и уехал в Москву), отбрил обоих кандидатов и вытащил из рукава третьего, который ему понравился по тому, как он ответственно подошёл к задаче по замене огнетушителей. (то есть на этой работе даже не пробовался, до этого руководил бульдозерным участком по выходным).
Итогом было тотальное фиаско. Новый человек не тянул, хоть и очень старался, затем примерно таким же образом был назначен главный инженер (2-ой человек сверху), а утвердивший их начальник начал вместо делегирования проверять каждый их шал.
Кончилось увольнением начальника и переездом на другое предприятие и на другую должность (уже в управление комбинатом, где-то в первых 5 должностях предприятия), и оставлением наследства в виде вот такого, выбранного им начальства.
Какая мораль?
Какой бы вы не были специалист, лояльное отношение к начальству и регулярная коммуникация перевесят профессиональные качества. Если не будете общаться вы, то найдутся другие, которые собственные провалы будут регулярно сваливать на вас (такого несговорчивого товарища).
У меня точно такой же опыт, ято и у Вас.
То же, в течение первого года работы стал помощником тимлида, а на следующий год тимлидом. А потом… вовремя не «не полизал попы», делал слишком правильно, чтобы порядок был, и прочие прелести кумавского корпоратива…
Хороший был опыт кстати, но не приятный конечно же.
Трайб - сбер, понятно, там горят все
С чего ты взял что проиграл?
Т.е. стать таким же дауном подхалимом - это победа.
Есть славный анекдот про бармена, что дешевле штраф платить, чем руку сбивать. Так и тут, грамотный инженер - всегда найдет себе работу. А жополиз - ой не факт.
я получил предложение на пару ступеней выше — набрать команду с нуля и реализовать проект для клиентов с нуля в другом большом банке в рамках глобальной трансформации
Про банк и некую Настю мне прям аж мозг резануло - слышал очень похожую историю про МТС-банк. Хотя... если это была Ксюша, то МКБ, если Света - ПСБ... впрочем, наверное, это очень типовая история... ну, или у меня очень много продакт-менеджеров знакомых накопилось.
Да-да, бритву Хэнлона никто не отменял🤷♂️
автору не хватило софтскилов
Вот это пожалуй ключевое. Он был хорошим технарем и возможно хорошим организатором процессов, но он проиграл в "политику", а в большом банке политика часто важнее, чем чистый код
И часто вы г-но на свою сторону затягиваете?.. А зачем?..
Рабочие интриги существуют сотни лет. Самый эффективный способ противоборства - вынуждать конкурирующую команду делать задачи и отчитываться о результате. А не сиять в своей голове.
Ну или плести интриги, но это разрабам редко дано, и слава богу.
Не всем дано быть хитрожопым, это врожденный навык😁
С высоты опыта уже как архитектор я стал примечать подобных Зин — очень опасные люди.
История забавная, но однобокая. Хорошо бы услышать версию Зиночки (или ее окружения).
Здесь резиновая Зина наплетет тебе о том, что у нее все хорошо, а автор рукожоп и неуч, да и просто токсичный и т.д. Зина это приспособленец-аппаратчик, который не просто там сидит, а благодаря тому, что умеет присесть кому нужно на уши.
Всегда нужно слушать обе стороны.
Лично знал одну такую, она пришла из Яндекса и жаловалась на токсичную атмосферу, ее бедную угнетали слова, что "команда не справляется" и "попытки давления на рабочие процессы", когда банально интересовались успехами и задавались вопросы, почему команда буксует :)
К счастью в отличие от Зины автора, эта Зина не имела обширных связей или родства с начальством и после нескольких ревью ее признали профнепригодной и расстались с ней.
Зинаида:
"В большом банке я взяла команду под проект глобальной цифровой трансформации. Посчитали, что ресурсов этой команды может не хватить и наняли рядом команду поменьше и к ней тимлида с рынка. Команда в целом хорошая, а вот тимлид - провал найма. Дедлайны у нас были жесткие, работать надо было в плотном взаимодействии с бизнесом, у них было много противоречивых хотелок. Для меня ничего неожиданного, я опытный руководитель: хотелки обсудила, приоритезировала. Работали много и успешно. А вот тот тимлид совсем потерялся: ему была выделена менее важная часть работ, с ожиданием что он бодро включится и начнет фигачить. Вместо этого он начал ... настраивать битбакет, разбивать ветки по гитфлоу. Ему много раз доносили обратную связь - мол бэклог фичей не ждет, а он все му-му, да му-му. Потом он еще говорил, что "Защищал команду от кала", лол. Первый этап они выполнили вовремя, а потом он начал откровенно тупить, перестал делать хоть что-то и типа внезапно понял, что тимлидство это не его. И тут все такие "########### ### #####". Разговаривать с ним уже не может, задачи сыпятся на нашу команду, мы работаем на выходных, хорошо что за деньги. Вместо того, чтобы как-то взять себя в руки, отдохнуть или переварить обратную связь он начал распространять слухи типа "Зиночка подхалим, подделывает ответы в ручках". Потом еще начал оправдываться типа у него людей мало и пришел просить еще - послали его конечно. Ну и в конце концов он вообще улетел в космос, его собственная команда начала посылать нафиг и в апреле 22-го, когда нужно было резать косты его уволили как самого бесполезного"
Ну если это официальный ответ, никто не прав, мне кажется. Работать в выходные это скорее ошибки планирования, крайняя мера, продуктивность будет еще хуже через пару выходных, если не будет текучки кадров. А вот услышать про приоритеты уже очень хорошо.
Я думаю, что это вольная импровизация на тему - "взгляд на д'Артаньяна со стороны коллег из соседнего отдела" ... но лично я примерно так всё и представлял :)
Самое ужасное, если такой человек подобные же подходы будет применять и к построению архитектуры - страдать будут опять же коллеги и заказчики.
Вообще, напоминает, как мне тут в комментах отстаивали важность настройки линтера: https://habr.com/ru/companies/skbkontur/articles/879706/comments/#comment_27903464. Примерно такие же "вайбы".
В общем, все переругались. И ничего нормально сделать не смогли.
.
подделывает ответы в ручках
Что это значит??? В каких ручках - шариковых, дверных, в руках маленького размера?.. Какие ответы???
И вот это:
Она посадила разработчика дергать ручки и подсовывать данные
Тоже не помогает. Ну явно не шариковые... Хотя их тоже можно дёргать, только зачем?
Можно дёргать дверные ручки, если дверь заперта - только как это помогает с подделыванием ответов (какие ответы?) и подсовыванием данных?..
Можно ещё, пожимая, дёргать маленькие руки начальства (допустим, у тамошнего начальства широкие плечи и маленькие руки - ручки)... Но зачем?! И как это помогает подсовывать данные?
Но самое страшное - походу, это только у меня когнитивный диссонанс, а все читатели тут всё прекрасно поняли. До маразма, вроде, ещё далеко... Неужели это мой русский настолько отстал от жизни? Или на самом деле знаю, но просто эпически туплю... Спрошу, наверное, ЧатЗПТ, а то вряд ли сегодня усну..
Ага, это сленг, а я не имею опыта разработки в русскоязычной среде.
Вот ответ из чата
Коротко по сленгу:
«Ручка» = эндпойнт API (обработчик запроса, handler, маршрут). То есть
GET /users/42,POST /loginи т.п.«Дёргать ручку» = вызывать этот эндпойнт (curl’ом, Postman’ом, автотестом) снова и снова, чтобы что-то проверить/воспроизвести.
«Подсовывать данные» = отправлять в ручку специально сваренный payload (тестовые/крайние/битые данные), чтобы посмотреть, как система реагирует, нагенерить состояние в БД, репродьюсить баг и т.д.
«Подделывает ответы в ручках» = в коде обработчиков временно возвращает фейковый ответ (захардкоженный JSON/HTTP-статус) вместо настоящей логики — для демо, для изоляции от внешних сервисов, чтоб фронтенд мог работать, пока бэкенд не готов, и т.п. По-взрослому это делается моками/стабами/фича-флагами или прокси, но в разговоре часто говорят именно так.
Пример для наглядности (Flask):
@app.get("/profile")
def profile():
if os.getenv("FAKE_RESPONSES") == "1":
return {"name": "Alice", "age": 99} # «подделали ответ в ручке»
real = load_from_db(...)
return real
«Дёргать ручку»:
curl -X POST https://api.example.com/login -d '{"u":"a","p":"b"}'
«Подсовывать данные» тут — это как раз тело запроса -d ... с нужными вариантами.
Этимология
Из англ. handler/handle → по-русски «обработчик», «хэндлер»; разговорно — «ручка» (как «ручка двери/тумблер» — pull the handle, «дёрнуть ручку»). Закрепилось в русскоязычном дев-сленге как синоним «эндпойнта/метода API».
У парня были АА, это очень шикарные оценки, значит он и начальству нравился в моменте и дело делал реально лучше всех, период. Так что все не так схематично просто.
Но токсик это хреновое обвинение. Его надо избегать.
Козни плохо и проигрышно, я за вооруженное перемирие, когда все вежливы и уважительны, потому что у другого пистолет, то есть хитрые мозги и близость к начальству
>> У парня были АА, это очень шикарные оценки, значит он и начальству нравился в моменте и дело делал реально лучше всех, период.
АА он получил перед проектом с двумя командами, когда работал сеньором и "фактически я сам выстраивал всю работу в команде". Ну то есть сеньору делегировали какие-то полномочия по процессам без коммуникации с другими командами и стейкхолдерами. Такое сочетание у него хорошо получилось, ему дали большую премию, его это "окрылило", потом его сделали формальным лидом и реальная работа лида его ошарашила и вогнала в депрессию.
Козни плохо и проигрышно, я за вооруженное перемирие, когда все вежливы и уважительны, потому что у другого пистолет, то есть хитрые мозги и близость к начальству
Блин! Сколько (лет) работал в закупках (ИТ-отдела), постоянно возникали ситуации, когда с главбухом вместо "Тань!..." и "Петь!.." переходили на "Татьяна Владимировна" и "Пётр Игоревич" =) ну, имена менялись, а принцип сохранялся. Обычно после очередного расхождения ТН и СФ на копейку, ну или после кривой ГТД от поставщика. Благо, уж лет пять этой ерундой не занимаюсь.
Версия Зиночки была бы написана на канцелярите и состояла бы из слов "синергия", "гибкость" и "бизнес-ценность". И в ней она бы конечно тоже была Д'Артаньяном
Я ходил в тимлидах 2.5 раза. Если меня спросят за суть этой позиции, то я порекомендую почитать, кто такие были бригадиры в ГУЛАГе. Декорации другие, но по сути совпадение точнейшее. Максимум ответственности при минимуме возможностей. Вам еще повезло, что получали премию. Я за свое лидство получал только аритмию и седые волосы.
Они и в цехе любого производство мастера тем-же самым занимаются. Собачья работа.
Честно говоря, автор идеалист, и занимался чепухой.
Я как тимлид, думаю это однобокая позиция с ограниченным кругозором, и на более высоких позициях ответственность никуда не девается. У начальника отдела просто вместо команды из 10 исполнителей, команда из 10 тимлидов. И чувства наверху жалеют не больше чем на уровне тимлидов. Бьют по премии. Просто с ростом народ учится не замыкать все на себе, а канализировать вниз с декомпозицией.
А закончилось всё вообще великолепно: несмотря на мои заслуги и ни одной проваленной КТ, меня в апреле 2022 года (сами знаете, какое было время) с жестким ковидом и температурой под 40 — которую я проводил в рабочих созвонах, я же ответственный идиот — просят написать заявление по собственному. Почему? А потому что Зиночка сказала, что ты очень нехороший человек и вообще токсичный, портишь нам атмосферу в трайбе. Доказательства? Может, поговорили с командой и взяли её мнение? Нет — зачем. Спасибо за выведенный продукт и два года работы, иди гуляй, за свои заслуги можешь взять два месяца накопившегося отпуска и искать другую работу.
Мне кажется, автор просто забыл, что мы все — обычные исполнители, а не владельцы бизнеса. Грубо говоря, мы просто строчки в штатном расписании. Ну попросили и попросили. Найди работу получше и не морочь людям голову, может, им без тебя спокойнее будет. А тебе без них.
Согласен, более того, даже рад, что так вышло. С ужасом представляю, что было бы, если бы я до сих пор там работал.
Но с формата увольнения я был в шоке. На практике мне приходилось и наблюдать, как увольняют людей, и самому этим заниматься. Как минимум, собираешь список претензий, ставишь сроки по устранению, обсуждаешь. А уж потом начинаешь разговор про «извини, но нам не по пути».
так а зачем по собственному-то? хотят уволить - пусть увольняют по соглашению, с тремя окладами. судя по упоминанию "трайбов" это те, у кого, как все знают, деньги есть.
или нервы тратить не хотелось?
да, так и есть. Плюсом время еще было тяжелое, были мысли про то, что скоро придется научиться готовить крысу на костре)
При упоминании "трайбов" вспоминается столовая на втором этаже, это лучше воспоминание об этом месте) Но этой не IT контора, тут дух иерархии начинается с самого низа и свои правила бюрократии...
В айти, мне кажется, проще найти работу с большей зарплатой и лучшими условиями, чем ждать, пока они там соберутся и уволят тебя сами.
Как минимум, собираешь список претензий, ставишь сроки по устранению, обсуждаешь. А уж потом начинаешь разговор про «извини, но нам не по пути».
Так ты бы мог и не увольняться, на хабре же полно статей было, что уволить по статье человека практически нереально. А всякие невыполнимые условия как на обычных работах в айти никто делать не будет, так как это просто заденет всех.
Как минимум, собираешь список претензий,
Это все правила игры для таких как ты и я(в прошлом уже). А когда тебя увольняет человек с реальными полномочиями(держит бюджет в руках), никто не будет там перед тобой кланяться. чек тест понять реально ли ты руководитель: можешь ли ты попрощаться с человеком не дожидаясь всяких там review, долгих разговоров и подшивок доказательств в папочку, которую потом несёшь своему руководству? Если нет, то ты не руководитель а говорящая голова, которая будет огребать от всех. Тебе ещё повезло, что на тебя не жаловалась команда. Бывает такие случаи, когда ты подхватываешь уже существующую команду, которую собирал раздолбай. А они потом наверх письма пишут, что ты их работать заставляешь. И к тебе приходят с претензиями. Как бы все понимают, что они ничерта не делают, проекты сдавать надо, но и команда должна быть довольной. Вот и крутись как хочешь.
Чем выше ты в иерархии, тем менее значимы технические параметры и более значим 3,14здёж. Просто потому что чем выше иерархия, тем больше бизнеса и меньше разработки. И таможним людям надо доносить "приложение работает", а не "победили проблему совместимости Х с У".
Ну а зачем было соглашаться на уход "по собственному"? Работайте дальше
Итог этого всего конечный такой - 40+ полное разочарование в жизни, ощущение как будто и не жил, хсн и выглядишь на 60 лет. А вы всего этого избежали!
На новом месте будет своя "Зиночка". Тут нужно отработать ошибки, а не просто сменить обстановку.
Есть места, где, чтобы выжить, надо быть... пофигистом. Сам недавно с такого ушёл - софт-скиллов не хватило спокойно наблюдать всё то безобразие, которое не можешь изменить. И, да, ваша хорошая работа никому не нужна, потому что пока вы тянете лямку, то хорошо получается "само", когда без вас что-то начинает сыпаться, то оказывается, что "и так сойдёт", зато нет этого токсичного душнилы.
На счёт смены роли на архитектора, как решение всех проблем... Не поверю. Думаю, что вам просто повезло со следующей компанией.
Про пофигизм вы правильно заметили. Я поэтому стал по-другому смотреть на своих лидов.
Про архитектора - правда. Сразу после этого инцидента я ушёл архитектором в другой крупный банк и дальше остался в этой роли, хотя предложения были интересные. Опыта и кругозора более чем хватило для этого, а курсы на Educative по архитектуре здорово позволили структурировать знания на тот момент. Хороший архитектор, на мой взгляд, это не про бюрократию и идеальное знание нотаций архимэйт, C4 и прочее, а про технический кругозор и опыт.
P.S. Ситуация, когда мои бывшие тимлиды отмалчивались на дейликах, меня тоже вымораживала. Вот баре.
Что-то слегка непонятно. Проекты схожие, но почему тогда в соседней команде людей чуть ли не в три раза больше изначально получилось? Несколько человек разницы я еще понять могу, но в разы...
Видимо все же разница была? И вовсе в не в «выстроенности процессов» ваше преимущество было, которое позволяло вам всей командой «чилить»?
Спагетти-код, понимаю, плохо. Да еще Зиночка с ее «не очень IT‑вещами» (аж морозом по коже, ага). И лид слушать про «открытые проходы в фаерволле» не пожелал, сказав странную фразу «зачем тебе вообще разработчики». А проекты схожие.
Мне кажется, что картинка с жестяным болваном на лошади очень в тему. Кто-то кого-то держит за болванов.
Проекты схожие, но почему тогда в соседней команде людей чуть ли не в три раза больше изначально получилось? Несколько человек разницы я еще понять могу, но в разы...
Бывает и в 10 раз. Зависит от того, кто как красиво штатку себе выбьет. Хэдкаунт под руководителем - это тоже ресурс (и вес). В т.ч. поэтому Зиночка все еще работает, а автору пришлось идти в архитекторы (кстати, у архов тоже бывают грустные истории)
Есть еще вариант, что в соседнюю команду взяли как раз норм народу под требуемые задачи в долгосрок, а описанная команда в итоге пахала в x2-режиме.
Объём‑то задач был похож, но из‑за подхода к процессу и разработке мы чилим, а они пашут как проклятые.
В начале было хорошо... А потом приходится признаться, что
Нагрузка росла. Я пытался где‑то сам делать аналитику, править баги по мелочи и смотреть пулы, укреплять своей тушкой там, где тонко
И жалобы аналитика скорее всего не на пустом месте возникли.
К этому в довесок:
вынужден решать все задачи команды, часто проглатывая собственную гордость. Уволить и быстро заменить — обычно не вариант
Т. е. видимо не угрожать сотруднику увольнением, а совместно решать рабочие вопросы — это проглатывать собственную гордость? По совокупности всего неудивительно, что так все закончилось, и последующий завал в работе команды тоже в этот вариант вписывается. Впрочем, автор сразу по-честному признался, что он д'Артаньян.
Да меня напряла картонность самой конструкции, которую нам обрисовали.
Соседняя команда под руководством Зиночки только делает вид, что зашивается, зарабатывает себе статус незаменимых, процессов не имеет, правда выполняет реальные хотелки бизнеса (тоже, видимо, с коварными целями?).
А в команде автора все по уму, процессы выстроены, код - не спагетти, хронометраж, бизнес посылают, зато «чилят» напролет все выходные.
Только почему-то лид заявил, что автору вообще разработчики не нужны. У них точно схожие проекты? Или лид, как пресловутая Зиночка, тоже не по IT-делам? Потому и аргументы не воспринял?
Я понимаю, каждый читающий проникается пониманием и сочувствием. Под 40 градусов, ковид, на мороз... Я понимаю, конторы бывают очень разные. Но...
А нам точно объективную картинку выдали?
в самом начале статьи дал сноску что ни на какую объективность не претендую, а именно поэтому нет ни одного имени действующих лиц ни названий организаций. Наверняка я был где-то не прав, и в частности один из первых комментариев был о том, что мне не хватило опыта и софтскилов что-бы красиво выйти из этой ситуации, да, так и есть.
Несколько человек разницы я еще понять могу, но в разы...
Например.
В одном из около госбанков. лет так 7-8 назад(лично застал 3 смены), каждый год меняли почти под 0 соседнюю команды из почти 100 человек. Логика была железной, в конце года не смогли на 100% закрыть хотелки, значит плохо работали, давай по новой. Да, команда эта команда всегда была аутстаф, но что есть то есть
В этом же банке была команда, которая из года в год заваливала проект, но вместо смены, получала расширение после каждого завала. Итого была команда в 140 человек, результатом которой был бекофис проект, державший около 3 одновременных пользователей. Почему не меняли их? Потому что РП был неплохим другом, кого-то из L3
Продолжая, этот же банк, была команда аж из 6 человек, которые тоже завалили проект(там мне кажется даже шансов не было с таким обьемом задач). Но им ни разу не дали новых людей, даже на время когда совсем авралы из соседней команды
Просто надо осознать, что в таким компаниях, никто не заинтересован в прозрачности, процессах, прогрессе и даже иногда в результатах. Главное получить квартальную, годовую и, желательно, проектную премии
И тут или смириться и работу работать или уходить. Сразу, после выгорания или ждать увольнения, каждый выбирает сам
Всё просто. Команда Зиночки постоянно на слуху, их много, они работают по выходным и постоянно превозмогают, у них дичайшая нагрузка и они справляются, то что это нагрузка из-за своих же проблем никого не интересует.
А в команде автора(если всё написано правдиво) налажены процессы, нет жестких факапов и никакого превозмогания нет, со стороны кажется что они прохлаждаются и недозагружены. А еще он наверное смеет отказывать начальникам в их хотелках или называет реальные сроки и трудозатраты, тогда как Зиночка согласная на всё и с ней проще работать.
Как старая история про сисадмина, который автоматизировал свою работу по максимуму и его уволили за то что он не бегает по заводу с горящими "глазами" и не тушит пожары, а сидит и прохлаждается)
P.S. У самого сейчас такая ситуация, так что прекрасно понимаю автора)
Должно было быть три команды, одна для одного продукта, другая для другого и третья - ядро, которая должна была писать общий функционал для обеих команд.
Так как команда Зиночки стартанула раньше и у нее были более жесткие дедлайны, команда ядра ей помогала, а дальше уже постоянные проблемы и косяки на их стороне так и не позволили сделать этой команде то самое пресловутое ядро и фактически разделение было такое, как я описал.
Я не понимаю, что вы вообще хотите от банка? банки это не про написание хорошего софта, это про дурацкие правила, стандарты которые не подходят ни одному проекту, дублирование кода, усложнение архитектуры до невозможности, использование инструментов с которыми невозможно работать, но у нас корпоративный стандарт, отсутствие технического бекграунда у руководителей проектов и выше, ну и как Вишенка на торте - куча согласований и интриги среди менеджеров и топов....
«Я эту задачу не буду делать, она сложная». На мои «я помогу, начни, там разберёмся, больше некому» — она просто вышла из зума и послала меня куда подальше.
Крутые дела, думаю я. Пишу ей, чтобы вернулась и обсудили ситуацию. В ответ: »Я не в ресурсе с тобой разговаривать». Великолепно. Первая мысль — может, у человека проблемы личного характера. Но нет, после многочисленных мягких заходов оказалось, она просто не хотела делать сложную задачу.
Не могу поверить, что такое могло произойти в реальности, просто какой-то сюрреализм и инфантильность)
Да ладно, у меня один коллега другого стулом хотел убить :), как доктор ватсон милвертона прям. Оба взрослые, яб сказал пожилые дядьки.
Люди они живые, и когда кому вожжа куда попадет неизвестно, но текст странный, яб ожидал гораздо короче и доходчивее идиом.
Суровая реальность. Если сотруднику "Вася, 21 год, не женат" захотелось вмазать энергоса и залипнуть в рилз, то увы, даже сам Путин его не остановит. Прямо сейчас передо мной такой сидит. Но я обычный сотрудник галеры, мне пофиг чем он там занят, просто факт.
Буквально вчера на созвоне инженер (который отчитывался о том, что у него сделано, а что нет) техническому директору сказал, цитирую: «долго ещё? Там ко мне человек пришёл, мне уйти надо». Не выходной, время рабочее.
Люди бывают разные, в том числе эээ… очень незамутнённые.
И молодец, а сто что, его владелец, а он раб? Закончилось рабочее время- до завтра, коллеги
у меня был кадр который мог подключится на созвон в нулину пьяный и начать всем высказывать то что он о проекте думает ;))
Что дальше было-то? С кадром.
ему сделали внушение и он еще гдето полгода проработал, потом начал в запои пропадать, и с ним решили прощаться
Внушение:;)))
как по мне, то алкоголику внушение не поможет, такого человека надо максимально выводить с ответственных должностей
на хабре я тут это однажды сказал, меня заминусили...типа "бухнуть нормально, люди меняются"
мой опыт говорит - что нет, не меняются
Ой, не хотел за живое дергать, но Вы не поверите, если есть желание… Короче мой отчим закодировался, и всё— не бухает.
Но случаи разные бывают…
Короче мой отчим закодировался, и всё— не бухает.
давно? тут такая штука, что они как мина замедленного действия
он может лет 5 не бухать, а потом бах и запой на три месяца
работал с одним коллегой, он стабильно кодировался и ровно по прошествии года начинал пить и шел кодироваться по новой
Обычная работа на обычной галере.
Новичку в IT статья могла бы дать пищу к размышлению, но не в коня корм: у них же "мотивация". :)
Если бы автору в начале его похода в "тимлиды" в Д’Артаньяны дать почитать его же "Мушкетёры двадцать лет спустя", что бы изменилось в его решении?! :)
Соседняя команда была хитрее: спагетти‑код, ни единого комментария, совершенно невероятные проблемы после минимальных изменений кода. Они готовили себе почву быть незаменимыми сотрудниками.
Как по мне - спагетти код, особенно на этапе MVP - звучит более чем адекватно, скорее неадекватно звучит когда сразу пытаются сделать хорошо.
Как гром среди ясного неба: на одном из созвонов по задаче мой системный аналитик заявила: «Я эту задачу не буду делать, она сложная». На мои «я помогу, начни, там разберёмся, больше некому» — она просто вышла из зума и послала меня куда подальше.
Тут вообще все очевидно - кого нанял, с тем и возишься.
А вы точно лид?
Как по мне - спагетти код, особенно на этапе MVP - звучит более чем адекватно, скорее неадекватно звучит когда сразу пытаются сделать хорошо.
Этот MVP потом никто не выкинет, как бы ни обещали, а начнут требовать допиливать, возмущаться почему это сложно и долго, и впаривать вину за срыв ИХ дедлайнов. Твое "я предупреждал, вы подписались, мы зафиксировали" не будет иметь никакого значения ни для кого.
Я проходил через это почти в каждой компании где работал с "MVP". Вот вот щас быстренько набросаем, а потом со знанием дела начнем заново. Да-да, именно так и будет.
Очень важны грани пресловутых "спагетти" и "хорошо". Главное беречь себя. От кода, с которым невыносимо работать, и от менеджмента, который будет на тебе ездить.
>>Этот MVP потом никто не выкинет, как бы ни обещали
Что логично. Это же MVP, а не демонстрационная модель какая-нибудь.
MVP это уже работающий продукт, но без некоторых фич.
MVP - это minimum viable product, ключевое слово viable. Вы, кажется, путаете с прототипом или PoC (proof of concept), которые должны быть утилизированы после своего этапа. MVP это такой продукт, который можно выкатывать на рынок в продакшн и затем допиливать. MVP можно выкинуть только если концепция продукта кардинально поменялась.
"называй хоть сюзанной, если тебя от этого прёт" (с)
аналогия с шалашом вас не убеждает?
Я пишу как инженер, который при выпиливании углов, всегда держит в голове идею как их потом обратно приклеивать. В этом и суть MVP. И вы ее совсем не уловили. Так что фрустрация людей, когда вы им говорите, что все в утиль, совершенно обоснована. Говорить с бизнесом на одном языке очень важно, но я так вижу терминологией вы особо не интересуетесь и подобные ситуации, где вы обещаете им одно, а на деле они получают что-то совершенно другое будут и дальше происходить.
Шалаш это никаким образом не MVP дома, весьма плохая аналогия. Шалаш это даже не прототип. Если вы строите шалаш, когда вас просят MVP дома, то вы сам себе злой Буратино.
Люблю разработчиков, изображающих профессионализм тем, что якобы понимают потребности бизнеса. Ребятушки, профессионализм не в том, чтобы удовлетворять любые сиюминутные хотелки, а в умении видеть подводные камни и говорить неприятное, когда это нужно. Все проблемы с MVP, о которых я слышал или которые видел сам, были связаны с тем, что бизнес слышит избирательно и переобувается на лету. На старте ты говоришь им, что желаемое ими требует команды с высокой квалификацией, пишется обычно на условной Java, требует сложно инфраструктуры с кафками всякими там и т.п., поэтому мы сейчас либо месяца три собираем нужную команду, по уму проектируем решение, закупаем необходимое оборудование и софт, разворачиваем инфру и потом ещё полгода пишем версию 1.0, с которой можно смело выходить на рынок, а после масштабировать и развивать без проблем, либо за месяц на коленке херачим MVP на Python, который способен минимально обслужить первых клиентов, но никогда не сможет вырасти в желаемый продукт, а развитие его будет стоить дороже, чем разработка с нуля. Бизнес слышит из этого только "девять месяцев" и "один месяц", выбирает второй вариант, а после релиза питонячей версии 0.1 возмущён, что функции в продукте не все, производительность не та, уязвимости какие-то устранять надо, а доработка почему-то медленная и проблемная.
Т.е. между хардкорной инфраструктурой на Java и на коленке сделанной поделкой на Python у вас больше нет никаких градаций? А вы в курсе, что на Java тоже можно делать небольшие MVP, которые потом можно постепенно масштабировать? Если вы на каждый новый проект, который должен начинаться с парочки клиентов, сразу предлагаете нанять всех инженеров с Фейсбука, нанести двадцать слоев девопса, реплицировать в 50 стран, то мне кажется не в бизнесе проблема, который не понимает, что такое MVP.
Вы позиционируете себя инженером, а значит должны бы иметь развитое абстрактное мышление. Однако, вам почему-то не хватило его для понимания абстрактного и чуточку гиперболизированного примера. Суть моей мысли в том, что всегда приходится делать выбор между скоростью, качеством и ценой, чудес не бывает, и бизнес на старте очень часто соглашается пожертвовать качеством, но почти никогда потом не готов заплатить за это своё решение вложением ресурсов в закрытие техдолга. С этого ветка обсуждения и началась.
Прям даже интересно стало - мой древний лапшекод больше на PoC тянет или на MVP? Просто оно в проде пару лет проработало
Скрытый текст
<?php
// подключаем библиотеку tcpdf
require( 'tcpdf/tcpdf.php' );
// подключаем файл с описанием функций получения данных и т.п.
require 'include/init.php';
function FillString($pdf, $c, $laststring=false){ // формирует строку табличной части
// ширина столбцов
$w = array(68,7,22,15,21,29,13,11,16,28,15,19,22);
$align = ($c[0] == "1") ? // если в параметрах номера колонок, используем альтернативное выравнивание
array("C","C","C","C","C","C","C","C","C","C","C","C","C") :
array("L","C","C","R","R","R","L","C","R","R","L","L","L");
// режим "перевода каретки" - все, кроме последнего - вправо
$lnmode=array(0,0,0,0,0,0,0,0,0,0,0,0,1);
$lastch = 0;
// вычисляем высоту строки по самой высокой ячейке
foreach ($c as $key=>$value) {
$lastch= ($lastch > $pdf->GetStringHeight($w[$key],$c[$key])) ? $lastch : $pdf->GetStringHeight($w[$key],$c[$key]);
}
// если текущая строка не поместится на лист, создаём новый лист и рисуем шапку табличной части
if (($lastch + $pdf->getY()) > ($pdf->getPageHeight() - $pdf->getBreakMargin())) {
$pdf->startPage();
//FillTableHead($pdf); // я не вывожу названия столбцов ТЧ на втором и следующих листах, но можно
FillString($pdf,array(1,2,'2a',3,4,5,6,7,8,9,10,'10a',11),false);
}
// если строка последняя и она не поместится на листе с "подвалом", создаём новый лист...
if (($laststring) and (($pdf->getY()+$lastch+55) > ($pdf->getPageHeight() - $pdf->getBreakMargin()))) {
$pdf->startPage();
//FillTableHead($pdf);
FillString($pdf,array(1,2,'2a',3,4,5,6,7,8,9,10,'10a',11),false);
}
foreach ($c as $key=>$value) {
$pdf->MultiCell($w[$key], $lastch,
$value,
'LRTB', $align[$key], false, $lnmode[$key],
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$lastch= ($lastch>$pdf->getLastH()) ? $lastch : $pdf->getLastH();
}
}
function FillTotal($pdf, $c){
$w = array(68+7+22+15+21,29,13+11,16,28);
$align = array("L","R","C","R","R");
foreach ($c as $key=>$value) {
$pdf->MultiCell($w[$key], 0,
$value,
'LRTB', $align[$key], false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
}
$pdf->Ln();
}
function FillTableHead($pdf){
$pdf->MultiCell(68, 18,
"Наименование товара (описание выполненных работ, оказанных услуг), имущественного права",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$nextY=$pdf->getY();
$thisX=$pdf->getX();
$pdf->MultiCell(29, 7,
"Единица измерения",
'LRTB', 'C', false, 2,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$nextX=$pdf->getX();
$pdf->MultiCell(7, 11,
"код",
'LRTB', 'C', false, 0,
$thisX, $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(22, 11,
"условное обозначение (национальное)",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(15, 18,
"Коли-\nчество (объём)",
'LRTB', 'C', false, 0,
$nextX, $nextY, true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(21, 18,
"Цена (тариф) за единицу измерения",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(29, 18,
"Стоимость товаров (работ, услуг), имущественных прав, всего без налога",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(13, 18,
"В том числе сумма акциза",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(11, 18,
"Нало-\nговая ставка",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(16, 18,
"Сумма налога",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(28, 18,
"Стоимость товаров (работ, услуг), имущественных прав, всего с учетом налога",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$nextY=$pdf->getY();
$thisX=$pdf->getX();
$pdf->MultiCell(34, 7,
"Страна происхождения товара",
'LRTB', 'C', false, 2,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$nextX=$pdf->getX();
$pdf->MultiCell(15, 11,
"цифро-\nвой код",
'LRTB', 'C', false, 0,
$thisX, $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(19, 11,
"краткое наи-\nменование",
'LRTB', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'M',
true);
$pdf->MultiCell(22, 18,
"Номер таможенной декларации",
'LRTB', 'C', false, 1,
$nextX, $nextY, true, 0,
false, true, 0, 'M',
true);
FillString($pdf,array(1,2,'2a',3,4,5,6,7,8,9,10,'10a',11),false);
}
//if (filter_has_var(INPUT_GET,'advice')) {
// получить реквизиты счёта-фактуры из внешней базы
// $rekv=GetSFParams(filter_input(INPUT_GET,'advice',FILTER_SANITIZE_STRING));
// разбор массива полученных реквизитов по переменным; не обязательно, но так проще читать/править форму
$sfn = "493";
$sfd = "10 января 2016";
$dealname = "ЗАО \"Напрасный труд\"";
$dealaddr = "101001, Москва г, Строителей ул, дом № 1";
$dealinn = "7701000001";
$dealkpp = "770101001";
$senderaddr = "---";
$recieveraddr = "---";
$advnum = "493";
$buyername = "ООО \"Вектор\"";
$buyeraddr = "101001, Москва г, Строителей ул, дом № 2";
$buyerinn = "7701000002";
$buyerkpp = "770101001";
$currency = "Российский рубль, 643";
$tch = array(array("Уборка помещений","-","-","-","-","22 777,04","Без акциза","18%","4 099,87","26 876,91","--","--","--"));
// в 14-м элементе массива параметров ожидается массив, содержащий номенклатуру
$totalprice="22 777,04";
$totalnds="4 099,87";
$bigtotalprice="26 876,91";
$director="И.И. Иванов";
$glavbuh="П.П. Петров";
// не используемые у нас реквизиты
$corrnum = "--";
$corrdate = "--";
$pboul=" ";
$pboulrekv=" ";
// Portrain/Landscape, mm, A4, unicode, UTF-8, diskcache, pdfa
$pdf = new TCPDF('L', 'mm', 'A4', true, 'UTF-8', false, false);
// отключаем вывод стандартных заголовков
$pdf->setPrintHeader(false);
$pdf->setPrintFooter(false);
// поля документа (левое, верхнее, правое)
$pdf->SetMargins(6, 10, 10);
// русские шрифты в стандартную поставку не входят - используем сгенерированные самостоятельно
$pdf->SetFont('arial','',8);
$pdf->AddPage();
$pdf->SetAutoPageBreak(true,10);
//начинаем вывод данных
$pdf->MultiCell(50, 15,
"Приложение №1\n"
."к постановлению Правительства\n"
."Российской Федерации\n"
."от 26.12.2011 № 1137", 0, 'L', 0, 1, $pdf->getPageWidth() - 50);
$pdf->SetFont('arialbd','',14);
$pdf->Write(7,"Счет-фактура № {$sfn} от {$sfd} г.");
$pdf->Ln();
$pdf->Write(7,"Исправление № {$corrnum} от {$corrdate}");
$pdf->SetFont('arial','',8);
$pdf->Ln();
$pdf->Write(3.89,"Продавец: {$dealname}");
$pdf->Ln();
$pdf->Write(3.89,"Адрес: {$dealaddr}");
$pdf->Ln();
$pdf->Write(3.89,"ИНН/КПП продавца: {$dealinn}/{$dealkpp}");
$pdf->Ln();
$pdf->Write(3.89,"Грузоотправитель и его адрес: {$senderaddr}");
$pdf->Ln();
$pdf->Write(3.89,"Грузополучатель и его адрес: {$recieveraddr}");
$pdf->Ln();
$pdf->Write(3.89,"К платежно-расчетному документу № {$advnum}");
$pdf->Ln();
$pdf->Write(3.89,"Покупатель: {$buyername}");
$pdf->Ln();
$pdf->Write(3.89,"Адрес: {$buyeraddr}");
$pdf->Ln();
$pdf->Write(3.89,"ИНН/КПП покупателя: {$buyerinn}/{$buyerkpp}");
$pdf->Ln();
$pdf->Write(3.89,"Валюта (наименование, код): {$currency}");
//$pdf->Ln();
$pdf->Ln();
$pdf->Ln();
$pdf->Ln();
FillTableHead($pdf);
$lines=count($tch) - 1;
foreach ($tch as $key=>$cstring) {
FillString($pdf,$cstring,$lines==$key);
}
FillTotal($pdf, array(
"Всего к оплате",
$totalprice,
"X",
$totalnds,
$bigtotalprice),false);
$pdf->Ln();
$pdf->MultiCell(54, 8,
"Руководитель организации\n"
."или иное уполномоченное лицо",
/*borders*/'', /*align*/'L', /*fill*/false, /*ln(0-R,1-CRLF,2-D*/ 0,
/*X*/ $pdf->getX(), /*Y*/ $pdf->getY(), /*resetLastHeight*/true, /*stratch*/0,
/*isHTML*/ false, /*autopadding*/ true, /*maxh*/0, /*valign*/ 'B',
/*fitcell*/ true);
$pdf->MultiCell(30, 8,
" ",
'B', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(2, 8,
" ",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(43, 8,
"{$director}",
'B', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(7, 8,
" ",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(54, 8,
"Главный бухгалтер\n"
."или иное уполномоченное лицо",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(30, 8,
" ",
'B', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(2, 8,
" ",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(43, 8,
"{$glavbuh}",
'B', 'L', false, 1,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->SetFont('arial','',6);
$pdf->MultiCell(54, 8,
" ",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(30, 8,
"(подпись)",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(2, 8,
" ",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(43, 8,
"(ф.и.о.)",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(7, 8,
" ",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(54, 8,
" ",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(30, 8,
"(подпись)",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(2, 8,
" ",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(43, 8,
"(ф.и.о.)",
'', 'C', false, 1,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->SetFont('arial','',8);
$pdf->MultiCell(54, 8,
"Индивидуальный предприниматель",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(30, 8,
" ",
'B', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(2, 8,
" ",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(43, 8,
"{$pboul}",
'B', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(15, 8,
" ",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->MultiCell(105, 8,
"{$pboulrekv}",
'B', 'L', false, 1,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'B',
true);
$pdf->SetFont('arial','',6);
$pdf->MultiCell(54, 8,
" ",
'', 'L', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(30, 8,
"(подпись)",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(2, 8,
" ",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(43, 8,
"(ф.и.о.)",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(15, 8,
" ",
'', 'C', false, 0,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->MultiCell(105, 8,
"(реквизиты свидетельства о государственной\nрегистрации индивидуального предпринимателя)",
'', 'C', false, 1,
$pdf->getX(), $pdf->getY(), true, 0,
false, true, 0, 'T',
true);
$pdf->Write(3.89,"Примечание: Первый экземпляр - покупателю, второй экземпляр - продавцу.");
$pagestotal=$pdf->getNumPages();
$headerX=10;
$headerY=6;
$footerX=$pdf->getPageWidth() - 45;
$footerY=$pdf->getPageHeight() - 10;
$pdf->SetFont('arial','',8);
for ($index = 1; $index <= $pagestotal; $index++) {
$pdf->setPage($index);
$pdf->SetAutoPageBreak(false);
if ($index<>1) {$pdf->MultiCell(/*W*/30, /*H*/0,
"Лист {$index}",
'', 'L', false, 0,
$headerX, $headerY, true, 0,
false, false, 0, 'T',
true);}
$pdf->MultiCell(30, 0,
"Страница {$index} из {$pagestotal}",
'', 'L', false, 0,
$footerX, $footerY, true, 0,
false, false, 0, 'T',
true);
}
$pdf->Output( "sf.pdf", "I");
?>Да, не бейте ногами админа за лапшекод - он не разраб от природы =)
Ну и да, процитировал я не продуктовый скрипт, а именно PoC, но от продуктового он отличается только заполнением массивов данных.
Как показывает практика говнокод родившийся из, ну нам надо быстро mvp, а потом все исправим, остается с проектом навсегда, ресурсов на исправить не будет, будут ресурсы навтыкать вокруг костылей.
Но та же практика показывает, что выпустить релиз лучше, чем не выпускать его вовсе в виду постоянных улучшений, доработок(на моей практике такое встречалось часто). Если нанимать на позицию разработчика - толкового человека(то есть ведущего разработчика с опытом), он используя именно этот самый опыт, сможет сделать так, чтобы это не превратилось в полную боль.
Я не отрицаю того, что выпустить релиз важно и почти всегда важнее чем иметь супер качественный код.
Я просто подсветил, что тема сейчас наговнякаем, запустимся, а потом сделаем как надо, в моей практике никогда не работала, весь говнокод из MVP годами жил без качественных переделок, обрастал костылями, частично приводился в порядок, но продолжал жить.
Причина простая редко когда дадут ресурсы приводить в порядок что и так "работает", тем более при наличии риска, что работать оно перестанет, да еще и новых проблем принесет.
кого нанял, с тем и возишься.
Это не всегда так же. Меня нанимали в одну команду на позицию teamlead и я у них поработал немного, где частично переформировать команду имело смысл, но возможности такой у меня не было.
С этой текучкой пришло первое осознание проблемы лида — у тебя встречи по 8–10 часов в день
Тут еще надо добавить, что теряются технические скиллы. Для меня это было одной из главных причин уйти с позиции лида обратно в разрабы.
За два года работы мои товарищи уже какие-то новые фичи языка используют, новые фреймворки, а я прокачал только умение говорить. Само по себе это неплохо, если человек планирует дальше развиваться в сторону менеджера. Но вот если менеджерская работа совершенно не интереса, то тимлидство - напрасная трата времени.
Как бывший "Директор департамента ИТ" не самой мелкой в РФ группы компаний - подтверждаю - за время "управленчества" (буквально года 3) настолько отстал от отрасли (повторюсь - я - админ по натуре), что догонять пришлось лет пять.
И да, в итоге я вернулся "в поля" - административка это не для технарей.
Судя по тексту, автор не овладел главным навыком руководителя - делегировать. Отсюда и куча проблем и выгорание
Можно делегировать аналитику, который ответит "я не в ресурсе" ))
Ну, это конечно был смешной ответ. Более опытный аналитик просто сказал бы "мне не хватает такой то информации для постановки ТЗ, буду собирать информацию, на это нужно 3 дня". И в 18 часов поехал бы домой.
Если лид готов рвать жилы за свою премию, то это еще не значит, что другие сотрудники обязаны делать то же самое. И со своей точки зрения они абсолютно правы. Так что делегировать можно все что угодно, только вот сроки сдвигаются.
"Не ходите, дети, в тимлиды гулять. В тимлидах гориллы, злые кродолилллы..."
Можно ходить в тимлиды, и даже в CTO/CIO, но надо четко понимать две вещи:
Не бывает ответственности без полномочий. Если ты отвечаешь "за все IT", к примеру, то и полномочия в части "всего IT" у тебя ультимативные. В меньших масштабах - то же самое.
Твоя команда - твои правила. В процессах, кадрах, бюджете - во всем.
Третья вещь будет следствием из первых двух. Ты будешь токсичным мудаком для всех, от кого ты прикрываешь своих людей. Потому что тебе часто придется говорить "нет" таким людям, которые имеют склонность, да еще и часто специально обучены ПРЕОДОЛЕВАТЬ озвученное им "нет" со стороны, например, клиентов.
То есть, тебе придется возражать профессионалам в "работе с возражениями". И когда они не смогут тебя продавить... Ну сам понимаешь, такое профессиональное фиаско люди не забывают и не прощают.
Соответственно, если ты не против несколько лет (или несколько десятилетий) побыть токсичным мудаком для изрядного количества людей - welcome to the piranha club, как сказал вроде бы Рон Деннис Эдди Джордану (но это не точно, я эту байку слышал еще в версии про Берни и Френка).
отличный комментарий, прямо в точку.
В моей ситуации, у меня был большой плюс - мой лид давал мне полную свободу в выстраивании работы с командой и процессов. За счет чего я и смог достигнуть результата.
Но, к сожалению, последнее слово за бизнесом, он же платит за банкет. А бизнес очень обижается когда твоя команда не подрывается на любое хочу и тыкает в процесс и бэклог))
Я себе этот коммент в рамку поставлю на рабочий стол.
Осознание, что для всех ты - токсичный мудак, если хочешь прикрыть команду, пришло ко мне только на втором году тимлидства. Началось с того, что внешний разраб назвал моего тестера «низкооплачиваемой рабочей силой» только потому, что QA часто воспринимают, как мартышек с гранатой.
Ну, такому просто должность тимлида не дадут. Есть же полно условных "зиночек", которые на все отвечают "будет сделано!".
Если ты хотя бы год токсичный мудак, то продакт лиды и другие агенты корпорации тебя под разными причинами уберут из лидов.
Проходили уже.
Основная причина - им пофигу на продукт, главное, чтобы написаные ими же целы были закрыты(хоть и костылями, а там уже они перейдут в другой отдел)
"Поэтому мой тебе совет, дорогой читатель: хочешь идти в развитие, но не умеешь и категорически не хочешь врать, подлизываться, плести сплетни и интриги, подставлять команду на эшафот вместо себя и забивать на всё болт — то лучше после того, как набрал опыт в разработке, аналитике, девопсе, мобилке, иди в архитекторы. Архитекторов не из системных аналитиков с хорошим техническим бэкграундом мало, а он очень хорошо помогает строить продуманную и красивую архитектуру. И влияние на конечный результат есть ощутимое, и Зиночки не мешают твоей работе и не особо тревожат. Win‑win."
После этого захотелось на хабре зарегистрироваться-таки.
С этого места поподробнее.
Это можно продолжить развиваться по уже полученному опыту в средах разработки, или нужно изучение дополнительного специфического софта?
И насколько можно добиться в такой сфере автономности своей работы?
Кстати, финансы - сфера, представляющая интерес по другим каким-то причинам в плане разработки в ней, или скорее из-за вышеуказанного материального аспекта?
Это можно продолжить развиваться по уже полученному опыту в средах разработки, или нужно изучение дополнительного специфического софта?
Опыт помогает и будет большим плюсом, но специфические знания конечно нужны. Очень много хороших курсов на дизайн гуру, они переехали из educative. Как первый шаг я всем их рекомендую проходить (серия grokking system design для начала). Дальше нужно изучить паттерны и нотации и можно пробовать искать работу на должности джуна архитектора.
Возможно дойдут руки описать свой путь и советы как быть хорошим архитектором, но не уверен что это тематика хабра.
И насколько можно добиться в такой сфере автономности своей работы?
Автономность по сути такая же как и у разработчика. К тебе приходят задачи, ты делаешь. Результат твоей работы в 99% случаев зависит именно от тебя. Реализация, конечно, другой разговор и требует софтов и умения договориться с командой и доказать что предложенный тобою подход действительно лучший. За три года ни одной описанной в статье проблемы у меня в архитектуре не случалось)
Кстати, финансы - сфера, представляющая интерес по другим каким-то причинам в плане разработки в ней, или скорее из-за вышеуказанного материального аспекта?
Очень тяжело выйти, обладая опытом финтеха предложений из финтеха будет сильно больше и они будут сильно понятнее)
С первой половиной статьи очень согласен. С тимлидством начинаешь утопать в созвонах, в анализе постановок, в планировании сроков. А по части разработки начинаешь медленно просасывать. Я осознал на себе, что через несколько лет подобной истории очень сложно написать какой-то фрагмент программы или написать свою функцию. Просто забываешь конструкции без постоянной тренировки.
А вот со второй частью есть вопросики. Там какой-то корпоративный жабагадюкинг произошел с Зиной. И непонятно, кто там прав, кто виноват, так как мы знаем только половину истории.
Тимлидеры выгорают гораздо чаще, чем в них выростают лишь по той причине, что для тимлидов самыми главными являются софт-скиллы, на которые все обычно забивают, именно из этого растёт большая часть проблем. Ну и конечно же в случае подобного назначения лучше всего начать читать книги по психологии. Я уже давно прознала, что они, как правило - работают
Я приходил к своему лиду и говорил: «Не могу сделать. Давай зафиксируем техдолг, скажем, что не успеваем». На что он мне: «А ты сделай как Зиночка. Она посадила разработчика дергать ручки и подсовывать данные».
Мне кажется, в этом корень всех проблем. Если ваш непосредственный руководитель неадекватный, можно попробовать наладить контакт с другими руководителями (соседними, вышестоящими) и перейти к кому‑то из них.
Тогда и напряг можно будет уменьшить.
У моего руководителя был очень большой плюс - он не лез в работу моей команды и не занимался микроменеджментом.
И вся эта ситуация, ретроспективой если подумать, случилась не из-за него, а из-за того, что у него тоже не было инструментов никаких и он фактически подчинялся бизнесу. Мой подход где я говорил бизнесу нет постоянно, очевидно для бизнеса был неприятен)
Хотя конкретно этот кейс неприятен и оправдания тут нет)
Возможно, вместо "нет" надо было говорить "окей, но нужно больше людей" и решались бы две проблемы. В теории, конечно, все зависит от ситуации.
Сам тимлид, раз уж написал, хотел сказать, что размеры команд у вас очень разные, был разный опыт, это вообще не сравнимые вещи и не стоит сравнивать.
"окей" было бы запомнено, и им бы тыкали потом в лицо при просранном дедлайне: "Но ты же согласился, что сделаешь";
"но нужно больше людей" было бы проигнорировано, потому что бюджета нет на увеличение ФОТ.
"окей" было бы запомнено, и им бы тыкали потом в лицо при просранном дедлайне: "Но ты же согласился, что сделаешь";
ой у меня так было, но я когда говорил Окей - сказал что напишу в резюме встречи что я не согласился, а вы настояли что так надо, а риски я подсветил... и я так там и написал ;)
Не сразу, игра в долгую, если все равно делать. Но самое правильное это двигать текущие задачи и чтобы они выбирали, что двигать. Со временем срочных хотелок становится меньше. Бывает даже, что после нескольких сдвигов задача уже не особо нужна. В общем, не обязательно говорить просто "нет" или работать по выходным.
Бизнес (а вернее его руководство), которое не умеет слушать обратную связь, доведет любой проект до состояния "теперь только в урну". А вместе с проектом и всех исполнителей. Поэтому оправданий тут быть не может - все кто в этой системе задержался, стали ее частью и несут часть ответственности за то что происходит и произойдет дальше. Включая вашего шефа. Ведь таки он хотел вас подставить с этим враньем...
И не соглашусь с остальными, что надо было вместо "нет" говорить как то обтекаемо или предлагать варианты... Считаю, что в таких случаях "нет" - это как лакмус. Какую реакцию покажет система ? Насколько она гибкая ? Насколько верхнее руководство способно вообще на конструктивный диалог. И возможно, если бы после первого "нет" вы "уперлись рогом", то всё произошло бы в ускоренном варианте - они бы вас уволили, а вы бы не потеряли время и не разочаровались. Просто конкретно это место для таких же людей, которым важнее грамотно соврать, чем делать реальную работу. Потому что за это там не бьют, а должны бы и больно. Но вот как недавний пример - соврал Трампу глава статистического департамента по данным о рабочих местах и место потерял. А Зиночка может врать годами и ничего... Т е даже если это вскроется, например с вашей подачи "через голову" вашего босса, то максимум ей скажут "а-я-я-й" и всё. А зачем тогда там работать ? Силы тратить, энергию... Пусть они там изовруться все. Рано или поздно либо высшее руководство начнет шевелиться, ли бо этот банк так и погрязнет в этом болоте (Да хоть пусть это "зеленый" банк будет - тучные времена кончились, а как при такой организации что-то можно заработать ?
У моего руководителя был очень большой плюс - он не лез в работу моей команды и не занимался микроменеджментом.
Это не плюс, это их правило выживания. Дистанцирование от принятия решений, приватизация достижений, делегирование провалов.
Мои разработчики — за чистый код, модульность, переиспользование решений.
вот тут на этом месте, учитывая остальное всё, надо понять что ЭТО не главное. точка.
Главное - попадание в дедлайны и удволетворенность клиента. к сожалению показателя "стоимость поддержки кода" в расчетах KPI департаментов 99% компаний - нет и врятли будет, а вот показатель "кошмар вокзал отходит, запилить сервис за 2 недели, у нас нет ни аналитики ни ТЗ ничего, все старые разрабы умерли, нас всех уволят если не сдеаем" - вот это очень важно бывает
сооответственно, качественный код и модульность это отлично, и ваша задача как тимлида увязать это с сумасшедшими запросами бизнеса, и САМОЕ ГЛАВНОЕ донести до верха риски, в письмах, разговорах.
также важно не делать так "я это делать не буду - вы бред какойто даете" - вы не сделаете, сделает Зиночка (криво косо, костылями)...а сделает Зиночка - ей премию, а вас уволят.. что оно потом падать будет и глючить - совсем другая история и чинить будет уже не команда Зиночки...но это будет както потом..а бизнесу надо вчера-сегодня
обидно и не честно? велком ту риал ворлд. тут всё так нечестно. вопрос стоит в том что нечестно или с вами или вы ищите другую работу где вам спокойнее.
отличный комментарий. На тот момент я был идеалистом и думал что качественный результат и прозрачность работы - это главное. Сейчас уже я понял что важен только результат и скорость, а косяки и постоянные сбои это не баг, а фича, на исправление которой можно запросить еще больше людей и бюджет.
Все так, но есть одна очень неприятная, прямо непреодолимая проблема. Она называется "фактор времени".
Действительно, говнокод часто менее затратен на короткой дистанции. Однако всякие штуки типа правильной архитектуры и хорошо пахнущего кода - они не для короткой дистанции придуманы.
Когда мы имеем дело с проектом, живущим заметное время (хотя бы год), и при этом "живым", имеющим ненулевой поток новых требований - мы обязательно сталкиваемся с фактором времени. Формулируется он очень просто: все всегда развивается от плохого к худшему.
По ходу времени абсолютно все деградирует. Простейший пример - люди забывают не только то, что и где у них в коде, но даже и то - зачем, по какой именно причине было сделано именно так. И это далеко не единственный пример, просто самый очевидный.
Так вот, правильные, дорогие и бесполезные на короткой дистанции штуки - начинают работать именно там, на долгой дистанции. Там они не просто окупаются для бизнеса, но окупаются многократно.
Тут не всё так просто, потому что время в начале проекта стоит дороже, чем в конце. А иногда, если не успеть в начале, то конца может и не быть.
А если ещё учесть, что в проектной компании или подразделении сокращение стоимости разработки не является приоритетной целью (а иногда и наоборот), то вообще всё запутывается.
Условно говоря, вашему менеджеру нужен быстрый результат сейчас, который вырастет в большой бюджет разработки потом, а вы ему предлагаете сейчас побольше поработать, чтобы потом меньше надо было делать. Неувязочка.
Я, по жизни, из мира SaaS, а не из мира проектов. Потому имею такое вот профессиональное искажение психики. Понять и простить :)
Все так, в Госе выделяют деньги здесь и сейчас, которые должны быть освоены и получен некий результат, удовлетворяющий часть хотелок заказчика. Далее идёт "развитие, масштабирование" и прочее.
На уровне разработки действительно выливается в тупые решения, которые не только крайне сложно дорабатывать потом, но и у которых забывается причина "зачем это вообще так"? Нужно это четко понимать и для себя решать, устраивает такое или нет.
Там они не просто окупаются для бизнеса, но окупаются многократно.
я был на проекте который пилили 3 года по всем канонам, и когда появился первый пилотный проект - закрыли целиком из-за исчерпания бюджета...но да, коммиты там красивые были, ООП, абстракции, документация
По словам автора всё выглядит действительно красиво: "я сияю, я внедрил ABC, XYZ и на дейликах выступаю дважды: в начале и конце, команду от проблем защищаю, а ещё у нас чистый код и документация".
Но между строк читается, что это всё враньё и очковтирательство:
1. (не смог обосновать увеличение команды) вести деловые переговоры не умеет
2. (всё делает сам) делегировать (а значит - доверять своим) не умеет
3. (история с аналитикессой) то ли команда изначально была не очень, то ли в процессе работы с таким замечательным человеком команда сдулась
от закрою сейчас эту квартальную цель с командой, а там‑то как будет время — сделаем рефакторинг, и всё, заживём по красоте.
ну это вообще инфантильное мышление, сразу видно человека с минимальным опытом энтерпрайз разработки. Никто никогда не даст тебе время для каких-то твоих личных доделок
и вообще мне очень не понравилась подача в духе "я вот такой хороший-хороший, всё-то правильно делаю, а все вокруг такие вот нехорошие и как-то так получилось, что у меня всё стало плохо". Внешний локус контроля
про минимальный опыт - согласен. Про остальное
1) очевидно, не хватило софтскилов и опыта. Слишком идеалистический подход к работе тоже внес существенный вклад
2) вот тут совсем неправда. Я не делал все сам, я лишь помогал когда какая-то из областей проваливалась и членам команды приходилось перерабатывать. Опыта в разработке и смежных областях хватало что бы быть небольшим плюсом в разгрузке проблемной области. В каждой зоне ответственности был человек, который разгружал в части контроля.
3) по одному человеку судить всю команду не надо. Этот кейс я привел что бы показать, что люди в командах очень разные и с некоторыми лиду будет тяжело и неприятно работать, но надо.
люди в командах очень разные и с некоторыми лиду будет тяжело и неприятно работать, но надо.
с такими можно, а иногда и нужно расставаться
я в своей карьере пару раз даже с начальниками своими расставался, всмысле не я уходил, я форсил смену начальника направления
1) очевидно, не хватило софтскилов и опыта. Слишком идеалистический подход к работе тоже внес существенный вклад
ну теперь то опыт есть, можно двигаться дальше, зачем уходить отсюда...мне например в руководстве интереснее чем код писать по таскам
Я сгорел и на тот момент категорично не хотел идти в управление. А сейчас в архитектуре нашел для себя нишу. И техника растет и влияние на результат есть ощутимое и главное - спокойно.
Про то, что нужно расставаться согласен, но были у меня кейсы где человек разворачивался на 180 после правильного подхода и из отстающего становился локомотивом команды. Категоричность иногда в минус играет и нужно перетерпеть и попробовать найти правильный подход к человеку, особенно если ценность есть и она для команды ощутима.
я в своей карьере пару раз даже с начальниками своими расставался, всмысле не я уходил, я форсил смену начальника направления
ну теперь то опыт есть, можно двигаться дальше, зачем уходить отсюда...мне например в руководстве интереснее чем код писать по таскам
Ответ на вопрос во втором абзаце, возможно, содержится в самом комментарии.
я в своей карьере пару раз даже с начальниками своими расставался, всмысле не я уходил, я форсил смену начальника направления
Ой, сколько же раз я себе начальников нанимал ))) нет, это не сарказм - просто я однажды понял, что постоянно мыкаться по совещаниям и готовить еженедельные (это ещё оптимистично - где-то видел чуть не ежедневные) отчёты - не моё, и перестал претендовать на высшие руководящие должности, а кто-то должен оценивать ИТ-директоров нанимаемых %)
Был у меня тимлид, который сгорел нахрен, потому что делал слишком много и закрывал всё, что был способен и ещё чуть больше. Не стоит так делать, как говорит нынешний, надо соблюдать work - life balance
Вот это разочарование! Когда думал, что бизнес платит бабки за красивый код, а не за фичи.
Идея про "щит от кала" очень благородная, но к сожалению наивная. Хороший тимлид в такой среде это не щит, это скорее дипломат или даже громоотвод. Его задача не отбивать все атаки, а уметь договариваться, искать компромиссы и правильно "продавать" работу своей команды наверх. Судя по всему с этим как раз и были проблемы
Впечатления от статьи - первый опыт автора лидом в кровавом ентерпрайзе :) Пришел в розовых очках, не справился - запаниковал. Реальность оказалось другой - бизнесу порой вообще все равно, что там и в каком виде под капотом крутится... (ну до определенного момента). А позиция токсичного Д'Артаньяна - проигрышная по умолчанию, особенно для начинающего (тут хороший управленческий опыт нужен и развитые софт. скилы, чтобы не сожрали)
На мой взгляд, слишком много личных разборок и претензий для технического специалиста, которому платят деньги за код (а точнее, за результаты работы кода). Какое вообще тимлиду должно быть дело до того, что происходит в соседней команде? Это вне его компетенции и крайне неразумно в качестве темы для обсуждения.
Я вот, допустим, часто удивляюсь, как живут люди в соседних офисах, но это их дело. Важно, что мы вместе создаём общий доход друг другу на зарплату.
На мой взгляд, слишком много личных разборок и претензий для технического специалиста, которому платят деньги за код (а точнее, за результаты работы кода)
Какое вообще тимлиду должно быть дело до того, что происходит в соседней команде?
тимлид это уже не разработчик кода, а на 1/4 менеджер, и если не отслеживать организационные риски вылета из дедлайна то вы плохой тимлид
по этому надо вообще следить что вокруг происходит, если сказать "я не я я код пишу, а с такими проблемами пусть деливери/РП/скраммастер разбирается" (которых может не быть или они слабокомпетентны или вообще забили на свою работу) ...то вы без работы очень быстро останетесь
Организационные риски вылета из дедлайна не имеют отношения к оценке работы соседей. И если уж на то пошло, то объективно хорошо иметь более тормозное соседнее подразделение; чего его ругать, если можно хорошо выглядеть на его фоне?
Конечно, если в конторе уж совсем всё плохо, то она развалится, но это опять-таки не проблема тимлида.
Короче говоря, более продвинутым коллегам нужно быть благодарным за возможность у них учиться, а менее продвинутым – за возможность быть с ними сравнённым.
Организационные риски вылета из дедлайна не имеют отношения к оценке работы соседей
имеет, если соседи тормозят вас и надо правильно эти тормоза на соседей свалить, чтобы дрожащим голосом не объяснять что блокер релиза в соседнем отделе...а вы наблюдая за таской соседей в жире со статусом "в работе" уже 4 недели которая не меняется, ничего не сделали...хотя очевидно что надо было озвучивать проблему РП уже тогда, а не в тот момент когда очевидно провалили дедлайн
Конечно, если в конторе уж совсем всё плохо, то она развалится, но это опять-таки не проблема тимлида.
тимлиду нужна работа? если закрыть глаза и ведро на голову - и проблемы - не ваши проблемы, то можно дожить и до закрытия продукта и направления...а потом возмущатся что просят написать заявление по собственному, а не увольняют в золотым парашютом
это я вот чутьли не свой реальный опыт описываю когда в одной конторе работал, когда моя команда осталась чутьли не одна из 5 просто потому что я не "пишу код, никуда не вмешиваюсь, пусть остальным другие люди занимаются" (с)
а остальных сократили...
Случаи, конечно, разные бывают, и вашу ситуацию я не знаю. Но в общем стоит дважды подумать, стоит ли оставаться в конторе, в которой сократили 4 команды из 5. В любом случае, это уже кризис-менеджмент, немножко другая тема.
В целом, компании в период роста, стабильного развития и умирания поддерживают разные процессы.
Он обижался и настаивал, чтобы обманывал именно я. Его. А он уже говорил наверх только правду.
Жизненно аж до боли. Будучи лидом крайне часто приходилось смотреть на менеджеров, которые всё прекрасно понимают, когда им говоришь неприятную правду, но сознательно и страстно желают быть обманутыми в моменте
Прочитал статью и ценю честность автора, равно как и смелость вводить процессы и делать правильные (или "правильные") вещи в компании. Лейтмотив же стар, как мир, — дорога ложка к обеду. Вы хотели вводить инструменты в компанию, которая изначально рассматривала их диковинными. Мы намного более инертны, чем хотим себе признаваться, отсюда такие, как Зиночка, являются более популярными, ибо они "свои среди своих" :)
Желаю вам найти коллектив, где не будут открыто предлагать лгать, а сразу будут процессы, которые вам не надо будет ставить. Дело — не в роли тех-лида, а в среде, где вы свои лидерские навыки применили.
У меня была похожая ситуация: был тимлидом от интегратора в банке XXX. Я скуф с авторитарными повадками. Собрал команду, выстроил процессы и никому (авторитарные повадки! :))) не позволял лезть в команду. Команда спокойно работала, я отбивал нападки, откусывался ну и руководил/техлидил - по итогу дали пинка с проекта одним днём. Старался заниматься процессами, а не политикой, но политика занялась мной :))). Аппаратные змеи 🐍 повесили на меня косяки и вышибли с проекта. Если честно - я был дико рад, что с меня сняли необходимость пихать шар из дерьма в гору. Пошёл в другую компанию разработчиком, и... через два месяца снова выпнули на тех.лида.
Не согласен с автором с тезисом "не ходите дети в тим.лиды". Но мне "не повезло" не поработать в "жабогадюкинских" компаниях.
Для меня позиция тим.лида стала ступенькой к "сделать то, что нельзя сделать одному". По этому категорически не согласен.
А если уже по сути, то любая "лидовая" позиция - э то всегда переход в "политику". И здесь я определю "политику", как установление правил.
Правил внутри команды. И по описанию автор справился с это задачей хорошо.
Правил на "границе" команды. И вот тут автор не справился. Чувствуется отсутствие отсутствие прозрачности с оунером. Из описания складывается впечатления, что не было с ним синков для обсуждения "проблем".
Правила "на границе" - это не только "отбивать задачи", это и правила оценки, правила найма и пр.
Наличие правил позволяет лиду(в самом деле это про любую позицию) самому принимать решения
- хочет ли он работать с такими правилами
- что делать при нарушении этих правил
И мне кажется, что автор "в горячке" просто перестал оценивать ситуацию и не справился с выравниванием ситуации.
Как гром среди ясного неба: на одном из созвонов по задаче мой системный аналитик заявила: «Я эту задачу не буду делать, она сложная». На мои «я помогу, начни, там разберёмся, больше некому» — она просто вышла из зума и послала меня куда подальше.
Крутые дела, думаю я. Пишу ей, чтобы вернулась и обсудили ситуацию. В ответ: »Я не в ресурсе с тобой разговаривать». Великолепно. Первая мысль — может, у человека проблемы личного характера. Но нет, после многочисленных мягких заходов оказалось, она просто не хотела делать сложную задачу. После напоминания о том, что я всё‑таки её руководитель и уволить могу, задача была в работу взята.
Автор вам не нужно быть тим-лидом, не ваше это. Тут прошлись по разным непонятным моментом, но меня вот это очень зацепило.
Во-первых для автора это было "Гром среди ясного неба", то есть ноль понимания как там у своих подчиненных, которых он вроде бы как защищал. После такого захода по хорошему нужно бросать все дела и разбираться что случилось пока команда не выгорела и не разбежалась ( 90% что уже выгорела конечно ), но автор занимается угрозами.
Коли произвел себя в дартаньяны, надо бы не Зиночкой называть, а Лили Винтер))).
И что это за слово такое знакомое - трайб? Это в Гугле так отделы называют? Я ничего не путаю?
Много кто через это проходит, но мало кто так честно пишет
Автор довольно знакомую картину рассказал, захотелось зарегистрироваться и прокомментировать)
Был один проект, в котором выступал как РП, но ресурсы использовались других команд. Т.е. вроде у тебя есть команда на 0,5 разработчика и 0,5 аналитика + твои ресурсы, но они не твои и так далее.
Основное управлять ожиданиями заказчиков и руководителей.
В какие-то моменты фича не делалась, чтобы архитекторно правильно её реализовать - нужно другое починить, т.к. потом ресурса переделать не будет
Одна из моих проблем была как раз в попытке защитить команды от критики, некоторых заказчиков от суровой правды (релиз их пожалений не принесёт эффекта, т.к. им нужно было сократиться до 1 человека, чтобы хоть как то фичу оправдать)
На следующей работе на позиции простого аналитика я увидел как выстроена правильная работа.
Как управлять хотелками без личного бренда, которые не принесут ценность продукта, при этом руками самих заказчиков. (Это не я вам отказал, а вы сами определили приоритеты исходя из потребностей бизнеса и эффектов. Да задача два года лежит, т.к. видимо эффект от её внедрения для вас и наших коллег не такой большой, как от других задач. Если помните, я предлагал вам обосновать необходимость задачи для топ-менеджмента и увеличить затраты. Как не помните? Вот мемо по нашей встрече в задаче)
Как журить команду, чтобы не переходить на личности, но при этом не вываливать на них все то, что говориться сверху
Почему результаты соседней команды важны и как помощь им, помогает твоей команде.
Почему важно не тушить пожары, а управлять изменениями. (Иногда показывая фильтры для задач руководителям, как у тебя видны влёты в спринте и как ты к ним готовился (около 25% времени заложено на них) - некоторые сразу посмотрят и другие свои команды)
Как разделить зоны ответственности, делегировать задачи/ответственности и их консолидация - почему не нужно отвечать за все самому. Тут как говорят: доверяй, но проверяй.
Автор ты вообще не понял как все устроено. Зиночка скорее знакомая/родственник коммерческого директора банка. Она как ребенок учится и набирается опыта. И училась как ни парадоксально на тебе. Она набралась опыта и ты стал не нужен их команде. Все теперь ты ей конкурент а не ментор вот тебя и отправили на пенсию. Как ни обидно но в жизни устроено так. Надо было тебе сразу оттуда уходить. И еще собирай факты чем больше тем лучше потом полезно доказать кто прав а кто нет.
Прочел статью и соглашусь. Много где так. Ибо много повидал команд и чудесным образом в основном растут и выживают только свои. Или попо-лизы). И это не зависит какая должность, лид ты или простой инженер. Сам потом сталкивался с тем, что очередной начальник это чей-то знакомый.
Не знаю, как вы из статьи такое поняли :) По сути автор, без реального опыта управления людьми и слабыми софт скилами, но с горящими глазами попадает на серьезный проект в роли лида (ментор, ага) и в реальности оказывается, что agile работает нихрена не по учебнику. В этом нет ничего страшного, набирайся опыта - учись у старших товарищей, раз такая возможность образовалась. Но автор делает совершенно неожиданные выводы, что в его провале виноваты абсолютно все вокруг кроме него - и Зина из соседнего отдела, пишущая «некрасивый» код и начальник не оценивший «красивый» код и требующий каких-то там дедлайнов и собственная команда по «неопределенной» причине посылающая его на …
Я оказался в похожей ситуации много-много лет назад, когда будучи просто разработчиком случайно получил лида в частично непрофильной для меня небольшой команде и все, что я знал в то время про управление - был законченный курс itil. Но именно поэтому я совершенно четко осознавал, что успехи проекта происходят вовсе не потому, что я хороший разработчик - это заслуги опытной команды, которая не давала сильно налажать начинающему лиду, а вот вся проектная лажа - это было мое неумение планировать и договариваться :) Хотя наверное большинство лидов примерно так и начинает :)
а вот вся проектная лажа - это было мое неумение планировать и договариваться
Как я понял из статьи, всё умение "Зиночки" договариваться сводилась к тому, что она охотно брала любые задачи, которые сваливали на её команду. Оттого весь её отдел и перерабатывал на выходных — потому что объем задач в разы больше, чем отдел способен выполнить в нормальном темпе. Почему её команду всё это устраивало? В статье говорится про двойной оклад за переработки. Если допустить, что ребята выходили на двойной оклад каждую субботу на полный рабочий день, то это, на минуточку, +40% к зарплате! Неплохо так-то.
И вот так получается, что такая "Зиночка" была удобна не только руководству, но и собственному отделу. Да, нормально не отдохнёшь, зато переработки так круто компенсируются. А если у топ-менеджмента и возникнут вопросы, почему это целому отделу платят полтора от их оклада, то у "зиночки" всегда будет железное обоснование — задач выше крыши, зашиваемся, не чаи гоняем ведь! Но вряд ли к ней будут так придираться, ведь она так удобна для бизнеса.
Чисто мои догадки, если что. Но в комментариях не особо обратили внимание на момент с двойным окладом за переработки, а ведь это тоже интересный фактор.
Предвижу вопросы в стиле "а что такого в двойном окладе за переработки?" — ну, не во всех компаниях переработки так круто компенсируются. Кое-где для расчёта бонуса за переработку берётся просто некая фиксированная сумма за час, и бонус выходит значительно меньше, чем если бы просто заплатили х2 от оклада за час работы
Для руководства, вообще говоря, переработки с двойным окладом невыгодны, как и любая другая работа за двойной оклад. Так что Зиночка здесь действует скорее в интересах своей команды, нежели фирмы.
Ну что ж, а у нас, держат урезанный набор операторов, а деньги от недостающих персон пилят между собой. В итоге мы перерабатываем (никаких х2 по субботам и воскресеньям). А топ-менеджемент даже и не подозревает о таких выкрутасах. Ну, я думаю, там у них кто-то в этом распиле участвует.
И не спрашивайте почему я там до сих пор батрачу.
Автор -
«Святая простота…» (кто сказал?!)
«Простота хуже воровства.» (народная мудрость).
Можно быть наивным, можно очень наивным, но быть ду…ом это уже слишком.
Проблема не в тимлидстве или ИТ. Проблема в большой компании. Все тоже самое происходит и на позиции любого менеджера проектов.
Проекты большие - сложность непонятна, польза туманна. Успех зависит много от чего, но мало от тебя. Детально в том, что конкретно делаешь вышестоящие не разбираются, смотрят на "результаты". Какая стратегия при таких вводных? Примазываться как к можно большему числу проектов - какой-нибудь да выстрелит, прикрывать попу бумажками, что б отмазаться когда они провалятся. Показывать как все сложно, рисовать красивые презентации о их преодолении.
Не умеете или не хотите? Идите в компанию поменьше. Или хотя бы не переживайте так, когда вас уволят как проигравшего в корпоративных играх.
Только профессия тут ни при чём, просто это не ваше.
Минимум, что я понял из описания, - вы не умеете говорить "нет", работаете с температурой, не ходите в отпуск
Обычно такое случается с теми, кто плохо понимает, что вообще вокруг них происходит. Люди думают, что их наняли писать красивый код, строить эффективные процессы или, боже упаси, делать мир лучше.
На самом деле, любого человека нанимают увеличивать вклад своего начальника и/или подразделения в темпы роста и финрез. Чем более здоровая среда, тем более понятные метрики за этим стоят. Но в конечном счёте бизнесу всегда нужны объём и маржа, а не красивый переиспользуемый код.
И да, если человека можно заставить уволиться п.с.ж. (без соглашения), то либо он выгорел настолько, что уже близок к депрессии, либо просто ещё не дорос до управленческой роли.
Господин топикстартер пишет, что спасся в роли архитектора. Мне именно это глаз резануло. Якобы мало архитекторов с тех-бэкграундом, которые не из бизнес-аналитиков.
Так фишка в том, что это разные архитекторы. Совсем разные. Из бизнес-аналитиков выходят бизнес- или около-бизнес-. Короче бизнес-центрированные архитекторы. Из технарей вполне себе хорошо получаются солюшн и системные. Системные, наверное лучше всего из девопсов и ДБА - это мое личное ощущение.
Поговаривают, что встречаются в природе еще ЫНТЫРПРАЙЗ архитекторы. Там похоже нужен такой набор скиллов, что не унесешь. Из кого таких ростят? И каким архитектором прикрылся автор?
Сейчас расплачусь, какая "сложная и нервная" работа и какая несправедливость, а получали небось прилично на руководящей работе по сути. Поработали бы на телефонной техподдержке в B2C за плошку риса у какого-нибудь провайдера ваша работа бы санаторием бы показалась. И кстати оттуда не увольняют даже отговаривают всячески, оттуда сами увольняются, став неврастениками.
Автор, а ты с дейликами не перегнул, тем более сам пишешь, что потом тебе на них нечего было рассказать и ты страдал? Не думал ли ты над тем, что когда ввел муштру, сам стал токсичным? В других отделах дейлика не было и люди потянулись туда, чтобы каждый день не е..ть себе мозг, чтобы на них такое сказать, тем более, как оказалось, можно было так не кранчевать. На чужом горбу в рай не вьехать :)
Собрались тут прямо эксперты управленцы в комментариях...
"трайб" это что то на зелено-банковском.
Почему я больше никогда не буду Team-Lead
ну не будешь и не будешь, нахрена об этом на хабре писать ?
Интересная тут собралась коллекция комментариев. Автор прямо и честно пишет, что предлагает субъективный дартаньявоский взгляд, но куча народа напихивает ему за "субъективизм", пишет, что надо выслушать обе стороны, и тут же, не отходя от кассы, додумывает, как оно всё было на самом деле.
Мне особенно понравились претензии, что автор "не умеет делегировать", и что "бизнесу нужны фичи, а не чистый код". Но каждый, кто в своей жизни сталкивался с корпоративным булшитом, знает одну простую вещь: бизнес просто не знает, какие фичи ему нужны. Таков закон жизни и это не из-за того, что там все дураки или какие-то плохие люди, просто на это есть ряд объективных причин. И DDD Эванса в лучшей своей части посвящена вопросу изучения бизнес-процессов разработкой совместно с бизнесом и дистилляции понимания этих процессов в явно определённых моделях, правилах и ограничениях. Т.е. это работа продукт-овнера, продукт-менеджера, аналитика и тим-лида понять действительную потребность бизнеса и найти кратчайший путь к её решению. Отсюда и возникает то самое "нет" тимлида, если это хороший тимлид, потому что бизнес часто приходит с хотелками вида "хочу кнопку в табличке на форме", а реальную потребность бизнеса можно закрыть иначе, лучше и дешевле, но для этого на каком-то этапе должен найтись человек со словом "нет".
А вопрос, кто станет этим "мистером нет" напрямую связан с "искусством делегирования". Потому что говорить это "нет" и предлагать более лучшие решения в первую очередь должен продукт-овнер, продукт-менеджер, бизнес-аналитики и только потом тим-лид. Но чем выше позиция к "начальству", тем сильнее у людей развита гибкость позвоночника и все эти важные для успеха продукта люди превращаются в обыкновенных "передастов". Бизнес хочет кнопку - Вася, сделай кнопку. Вот оно - искусство делегирования. Манагер "делегируя" задачу разработке и свою харизму перед бизнесом не портит и себе мыслями голову не нагружает. О сложных вещах пусть разработка думает, обязанность думать и разбираться в сложных вещах менеджер "делегировал" вниз по стеку.
И тут вопрос, кто окажется тем "Васей", на котором остановится эта цепочка делегирования. Часто таким человеком становится тимлид, который знает, что "копать" всё равно ему, поэтому он не поленится "думать" прежде чем взяться за лопату. Такой тимлид прослывёт токсичным душнилой, зато его команда не будет из спринта в спринт закапывать и откапывать стюардессу. Впрочем, не редка ситуация, когда тимлид сам овладел "искусством делегирования". Тогда он встроится в линейку начальников, с которыми бизнесу приятно общаться, а тащить работу будет пара сеньоров. Такое тоже случается сплошь и рядом, люди быстро учатся искусству пофигизма.
Все в точку. Лучше и не скажешь.
Причем, что интересно, вменяемому бизнесу тоже не нужен "передаст" в контакте со стороны IT. Потому что люди тоже не вчерашние, и понимают, что их "хотелки" - это еще не решение. Им самим хотелось бы "обстучать" их об компетентного и конструктивного человека. Но опереться, как водится, можно только на то, что сопротивляется. Передаст тут бесполезен.
Мне на днях рассказали историю про техдира, который был уволен через месяц после приема на работу. Основной поинт был именно в том, что человек увидел своей основной задачей - на совещании топ-менеджмента докладывать статус по задачам в разрезе разработчиков.
бизнес просто не знает, какие фичи ему нужны
Бизнесу вообще не нужны фичи, ему нужна прибавочная стоимость. И он об этом прекрасно знает. А фичи нужны технарям со стороны заказчика и исполнителя.
Раньше вообще было хорошей практикой подписывать «лист/список должностных обязанностей».
Поэтому мой тебе совет, дорогой читатель: хочешь идти в развитие, но не умеешь и категорически не хочешь врать, подлизываться, плести сплетни и интриги, подставлять команду на эшафот вместо себя и забивать на всё болт — то лучше после того, как набрал опыт в разработке, аналитике, девопсе, мобилке, иди в архитекторы.
В архитектуре те же яйца только в профиль.
Интересно, а как этот случай классифицируется в теории, например, через уровень зрелости хотя бы методик Спиральная динамика и Tribal Leadership.
На такие роли нужно подбирать устойчивых к социальному стрессу. Важно испытывать позитивное состояние от людей, их проблем и помощи, заботе.
Считаю это ошибка тех кто Вас нанимал, так как не поняли, не протестировали и лично Вас, что сразу не ушли, а терпели боль и хронический стресс, негатив на долгом промежутке.
Также хочется сказать, что такой специалист должен работать в паре с психологом, иначе Вам придется решать психологические проблемы людей.
ИМХО очень много верных вещей в каментах. Очень важно в корпоративной культуре уметь делать "что скажут и как скажут" а не так как вы считаете правильным. В любой сложной системе компетенции очень не равномерный и речь не про соответствие должности, а про то, что заказчик не знает как правильно и эффективно решить проблему, он шарит за другое и тратить время на освоение других профессий ради того что бы вникнуть в понимание решения конкретных задач это глупая стратегия на среднем и высшем уровне управления, там уже в зоне контроля сотни профессий, во всем не сможешь шарить.
Переведу в медицинский, для понятности) В итоге у высокого начальства есть боль, они ее спускают в виде задачи - сделайте что бы было не больно, ибо нет понимания что надо вникать, в боль мешает здесь и сейчас. Задача падает во врага, который тут же начинает расписывать программу с выездом в санаторий, сменой образа жизни, питания, таблетками, процедурами, он решает корневую проблему. А заказчик хотел снять боль. До дех пор пока некомпетентный не поймет, что его знания и понимания недостаточно для правильной постановки запроса, будет конфликт, будут обезболы один за другим, местечковые решения и возможно не будет лечения пока боль не превратится в открытую язву и чел не попадет на операционный стол. Все люди такие, даже те, кто думает, что они вот прям всерьез про здоровье думают они ошибаются. Это буквально на наших имманентных качествах механизм. В бизнесе так же. Им нужно самим тыкаться в их решения и видеть что они бесполезны что бы принимать решения дальше более правильные. Все рассказы, что компании и корпорации могут самостоятельно накапливать базу знаний и ей пользоваться это дерьмо собачье, всегда это конкретные персоны со своим багажом знаний и этим персонам нужно принимать решения и видеть результат их решения.
Если не видеть и не признавать этой сиецифики, то любые управленческие задачи могут сталкиваться именно с такими проблемами как в посте "хотел красиво, эффективно и правильно" а просили не этого.
Что-то я не понял в чем проблема-то?
Да такое бывает. Хочешь стать куском дерьма как Зиночка - будь как Зиночка. Не хочешь - не будь, найдешь нормальную команду и компанию. Меня тоже запихивал в такую дебильную позу, а я не лез. Да увольняли, получил выходное с окладом в пол-года. Отдохнул 2-3 месяца и спокойно подобрал подходящее место.
Хочешь в Архитекторы - или в Архитекторы. Но там тоже можно много накосячить и выгрести. И девелоперы могут тебя посылать, потому что они лучше знают.
У меня самый эпик был, когда девелоперы вместо написания документации, выдавливали пасту из не вычитанных фантазий ИИ. И доказывали, что иначе не бывает.
История стара как мир. Тупая пиздень, которой ты лично не понравился, настучала на тебя начальству и тебя уволили. Я вообще в афиге, на кой хрен вообще этих тупых созданий начали брать в айти? Делать ничего не умеют, кроме как чесать языками и вносить разлады и ссоры в коллективы.
"на одном из созвонов по задаче мой системный аналитик заявила: «Я эту задачу не буду делать, она сложная»" - ну типа за неё эту задачу должны были делать другие люди, а получать за это зарплату естественно она. Чё серьезно, вот так просто можно сказать и не работать: "я не буду это делать, эта сложнааа"? Ну короче понятно, кто на тебя жалобу кинул, ведь ты заставляешь работников заниматься их прямыми обязанностями.
И почему они все разговаривают, как вагини блоггерши из инфоциганских курсов Инстаграма: »Я не в ресурсе с тобой разговаривать»
Совет - присматриваться к будущим руководителям, выбирать крепких технарей.
Посредственные тянут посредственных, крутые крутых. Друг с другом они не уживаются.
Я вот чувствую, в чем была проблема. Не надо быть самым умным, не надо работать с температурой 40 и все хватать и успевать. Расслабься и расслабь людей. Системный аналитик бесилась из-за того что слишком большую задачу ей дал за слишком короткий срок. В корпомире 3 дня работают, 2 дня спят. Некоторые вообще ничего не делают, а сидят балластом на балансе. И с Зиночкой... Любое высокомерие просачивается в общение. Главное правило: стараться не показаться умнее своих конкурентов и сокамерников.
Это даже не про тим лид. Я для себя обнаружил что есть люди у которых есть реальные жизненные убеждения и принципы и они на них опираются, но большинство не имеют такого, зато они фокусируются на адаптации. Думаю ваша проблема в том что вы вовремя не раскусили окружающую вас действительность и подумали что ваше видение о том как лучше кому то интересно. Но видимо это видение предполагает что остальные люди будут также заинтересованны в реальной оптимизации а не прикрыванти своей пятой точки и как правило это не так. Я не имею никакого опыта управления, но думаю что довольно очевидные вещи говорю. О5 же это не про тим лид, это про людей в целом.
Почему я больше никогда не буду Team-Lead и тебе не советую