Comments 61
Судя по статье, автор знает, что и как нужно (с)делать. Интересно будет почитать, как он лично попробует применить своё видение процесса "и швец, и жнец, и на дуде игрец" в конкректном продукте.
больше похоже на то, что автор - очередной эффективный менеджер с отвлеченными красивыми речами
Просто они "ту биг ту фолл, всегда отсыпят из бюджета, есичо" - вот и могут себе велеречивые статьи позволить, пока другие ошалевают от рыночных перипетий.
Я инженер-разработчик.
Тоже разработчик и уж собирался коллегам выше подсветить, что всю свою карьеру (она недолгая еще, почти 5лет коммерческого и пару лет хобби до этого) так именно и считал и до сих пор считаю (да и при стартье ком.карьеры так меня-джуна учил мой наставник, с опытом в 10лет на тот момент уже)
Единственное, для меня странно, что это только сейчас стало актуальным (если правильно понял в тексте), кмк это в целом более зрелый подход и должно было быть изначально
Ну и 2 поинта вдобавок/подтверждение:
знать с кем работаешь - важно/нужно/полезно (это про «разбираться во всех процессах кто и где что делает)
Узкая специализация ведь тоже не самого начала была, она же пришла взамен исходной культуре «айти», когда бородатые дядьки все сами придумывали и воплощали, а там для масштабирования этого ремесла и начали дробить на более простые/узкие направление (пока писал вспомнил пословицу про сильные люди приносят хорошие времена, а хорошие времена порождают слабых людей… - будто это оно и есть, что возврат к истокам)
Я делал так.
Сам так работаю и не один.
перефразируя известную цитату "я так могу, и каждый это может, вопрос лишь в том, как спорятся дела".
На небольших проектах думаю многие так начинали, но в статье, насколько понял, этот подход советуют и для энтерпрайза. А там, подозреваю, обилия специфичных кейсов просто взрыв состояний произойдет в голове бедного экспериментатора.
Я думаю проблема людей в финтехе в том что у них заказчик это они сами, заказчик банка это сам банк. Да у банка есть клиенты, но они жалуются работникам банка которые в свою очередь и являются заказчиками каких-то фич. Т.е. здесь заказчик и исполнитель это по сути коллеги работающие в одной организации. И да тут можно коммуницировать, обсуждать, "быть в теме всего" и т.п. Большинство работников "сидят" на работе по 5-10 лет и уже "свои в доску". В такой атмосфере Ваш стандарт может работать. А теперь посмотрим на другие области где заказчик это обычно внешнее лицо с непонятными целями, непонятной мотивацией и лицо это может быть как физическое одно лицо, так и юридическое лицо или группа лиц с которым если и есть связь но для принятия решений требует согласований неизвестной группой лиц на их стороне с которой у Вас нет четкой и всеобъемлющей связи и всеобъемлющего понимания того что они делают и зачем. К тому же сегодня команда делает мобильное приложение в медицинской сфере а через 4 месяца социальную сеть для уборщиков, знать глубоко каждую предметную область в таком темпе даже не сложно а невозможно. Поэтому и сложилось разделение которое Вы критикуете и предлагаете упразднить вот только такое если и возможно то только в Вашей отрасли и то не факт что везде.
да тут наверно вы правы - крутясь внутри финтеха в одних и тех же задачах много лет возникает иллюзия что выгоднее разработчику иметь бизнес навыки на высоком уровне.
тем более что заказчик этжом ниже и если коммуникация налажена то все прекрасно.
а если заказчик в другом городе или доступен только по конференциям - ну автор про это наверно и не знает.
короче специфика
В заказной разработке и в финтехе та же проблема, что вы описали, но даже там можно +- применить большую часть идей из статьи
А что касается «сегодня мед.апп, чз 4 месяца соц.сеть» - наверно к счастью, но я и есть экземпляр этого человека, и да, я с каждой из областей разбираюсь попутно/заранее и если не к середине, то к концу разработки я уж точно необходимый минимум предметки освою (иначе уверен, что сделаю херню полную, а не проект)
З.ы. Как и автор выше в обсуждениях пишет - у меня та же история: большая команда, супер-апп (не горжусь за такое решение монструозного аппа, но заказная) со всем, что вокруг да около финтеха/соцсетей/adTech
В заказной разработке и в финтехе та же проблема, что вы описали, но даже там можно +- применить большую часть идей из статьи
Не конечно делать все разработчику самому можно применить. Я Вам даже больше скажу я застал времена когда такое уже было и считалось нормой. Я например помимо разработки катался (и не на служебном транспорте) к заказчикам и ставил/обновлял им разрабатываемое ПО иногда в редких случаях еще катался и исправлял его работу. Общался на объектах с работниками о том что им неудобно и не нравиться в ПО которое я делал, обновлял документацию на ПО, тестировал тоже сам и да нес полную ответственность за все это. И это работало по одной простой причине, само по себе ПО было не сложным по современным меркам, у меня было достаточно времени чтобы и заниматься разработкой и всем остальным, сейчас например на моей текущей работе с моей текущей нагрузкой я не представляю как можно делать что-то еще за пределами разработки.
А что касается «сегодня мед.апп, чз 4 месяца соц.сеть» - наверно к счастью, но я и есть экземпляр этого человека, и да, я с каждой из областей разбираюсь попутно/заранее и если не к середине, то к концу разработки я уж точно необходимый минимум предметки освою (иначе уверен, что сделаю херню полную, а не проект)
Хорошо, Ваш клиент это китайская компания заказавшая приложение для торговли лапшой в Куньмине. Потом идет социальная сеть для уборщиков в США. Далее криптобиржа для австралийского клиента ну еще один маркетплейс для продажи кошерной пищи. Все проекты идут по 3-4 месяца т.е. условно через полторагода Вы бы разбирались в куньминской лапше, как работает рынок клининга в США, стали криптаном и естественно знатоком кошерной пище? Я думаю нет, Вы максимум что приобрели бы знания принесенные Вам через тз и/или общение с заказчиком и дополненные гуглингом.
Да, за пару тройку месяцев гуру уж точно не стать, но уж точно буду знать больше чем «джуны» в этом деле (например, чем начинающий менеджер в сфере клининга, для которого я бы и написал софт)
про t shaped шла же речь в посте, т.е. автор, как и я сам признается, что экспертом во всех сферах физически не стать, т.к. эксперты мы именно в разработке, но ввиду междисциплинарности профессии - надо не хуже джуна/мидла сферы, для которой пишешь ПО разбиратсья в предметке, иначе велика вероятность, что продукт будет сделан либо работает, но оч.кривой, либо сразу провальный, ибо делал тот, кто понятия не имеет что значит бизнес клининга
про t shaped шла же речь в посте, т.е. автор, как и я сам признается, что экспертом во всех сферах физически не стать, т.к. эксперты мы именно в разработке, но ввиду междисциплинарности профессии - надо не хуже джуна/мидла сферы, для которой пишешь ПО разбиратсья в предметке, иначе велика вероятность, что продукт будет сделан либо работает, но оч.кривой, либо сразу провальный, ибо делал тот, кто понятия не имеет что значит бизнес клининга
Ну т.е. заказчик, который является экспертом в какой-то области, пишет ТЗ, отдает его в работу Вам. Вы читаете его а потом читаете интернет где написано что что-то работает не так и делаете как Вы считаете нужным потому что ну Вы же стали лучше чем джун разбираться в какой-то области? Если нет то знание предметки за пределами получаемой из ТЗ и общения с заказчиком Вам вряд ли нужно и его наличие вряд ли как-то сильно повлияет на то что проект станет успешным.
На данный момент не имею опыта работы в формате, что вы описали (мне дают тз и я делаю по нему/по своему), ко мне обращаются с обрывками контекста "хотим что-то" или "хотим вон как у тех ребят, ток с нашими фишками", а я уже занимаюсь погружением в предметку и далее реализацией того, что хотели (если упрощенно и по верхам сказать, кншн же, есть шаги обсуждения/согласования с заказчиком то ли он хотел увидеть)
основаная тема материала - все делают все.
если ты будешь общаться с бизнесом, то ты уже не будешь разрабатывать - будешь все болшье и больше тратить время на совещания и меньше на разработку.
то есть из разработчика превратишься в менеджера - легко деквалифицироватся.
и тем не менее как правильно сказать невозможно - неясно что такое правильно.
анекдот "быстро качественно и дешево" это не анекдот. у автора есть пример быстро и качественно?
правда в чем качество ( критерий) и быстрота - это какой срок?
что дочно можно сказать - бизнес задача реализована или нет. как реализована - оценить можно
Теперь важно не делать разработку ради разработки, а вести бизнес вместе с заказчиком.
Процентом от прибыли этого бизнеса тоже поделятся?
Как долго они говорили гордое "Фи...". И вот пожалуйста - мутировали в 1С-ников :)
С таким подходом автору в команду нужны ВСЕ сеньоры или даже тимлиды, а может - РМы. Процесс разработки и стоимость проекта устремятся в бесконечность.
Удачи ,в общем.
Так зачем эти айтишники нужны вообще, берете и всем своим менеджерским отделом начинаете разрабатывать по чатгпт. Ух сколько сэкономите!
Всё это замечательно. Понятно кто вам нужен. Но в этом тексте потеряно главное.
Настоящий профессионал работает ради успеха бизнеса. Но не бесплатно. Какова оплата труда настоящего инженра?
Давайте посмотрим. На сайте компании "Гапзромбанк", есть ссылка на вакансии - они внезапно на hh. Из 100 с лишним вакансий - только одна "с деньгами" - 68 тысяч - руководитель группы обработки звонков.
Все остальные вакансии из той категории, по которым HR скажет "мы платим по рынку". Но ведь рынка Software Engineer в России нет. Значит платить будем как обычному кодерку из любой другой компании.
Окей. Предположим, что платят хорошо? Компании нужны инженеры обладающие огромным опытом - умеющими выбирать абстракции и минимализм. Фильтр по опыту - удивителен. Нужны специалисты до 6 лет опыта. Это те самые опытные инженеры?
Фильтр по опыту более 6 лет (ну лично у меня - 20). 2 вакансии линейных сотрудников. Остальное "руководители" (СТО, лиды и прочий совершенно не инженерный мусор).
Одна вакансия для QA, от которого не требуется знать ничего из автоматизации (и это ведущий инженер), вторая - Senior Java Developer. От которого требуется первичное тестирование написанного (прости господи), на стендах. Это видимо и есть лучшая инженерная практика из текста в статье?
По итогу. Мы не имеем корреляции между текстом "желаемого" в статье и в найме. Конкретный вопрос: кто эти "вы", кому нужны инженеры? Я как профессионал задаюсь этим вопросом, каждый раз когда читаю подобные тексты.
Ну тут из статьи ясно только одно, идти в этот Газпромбанк нужно где-то по приоритету в нижней части списка, повыше чем в один красный поисковик, но все еще, уж очнь хотят семируких Шив, а платить не очень хотят, печаль.
а с чего вы решили что оплачиваемые вакансии куда-то вообще выставляются - вы смотрите заявки на рабов
Судя по тенденции в нашей прекрасной, ждём популяризации и возвращения в штатки инженер-программистов, инженер-системотехник.
Эта статья вызвала у меня очень сильный эмоциональный отклик, буквально "Вьетнамские флешбекти" со времен, когда я только начинал свою карьеру разработчика.
Это было 15 лет назад, и мне больно от того, что за это время мы пришли к тому же самому. Извиняюсь за тон - эти темы важны для меня на личном уровне; в конце концов, эмоции - это часть, которая делает нас людьми.
Вот несколько вопросов и моментов, которые я хотел бы обсудить.
В заголовке написано: "Нам не нужны кодеры". Вам - это кому? Тем, кто сам не способен стать ни кодером ни инженером, но зато уже готов требовать это с других, повышателей уровня инженерной культуры, стандартизаторов и прочих "эффективных менеджеров"? Без сомнения, кто-то все таки должен делать реальную работу, а не просто требовать ее с других. Вы пишите "Отвечать за результат, ... быть готовым нести ответственность, не деля её" и тут же перекладываете все на разработчиков, дескать это они должны меняться и брать ответственность, но не вы. В древности, ровно в то время, когда не было, как Вы выражаетесь "узкого разделении труда", было такое слово - лицемерие.
Что касается узкого разделении труда - это не прихоть программистов. Просто сложность и количество информации выросло в разы за 20 лет, и освоить сразу все на хорошем уровне практически невозможно. Это закономерный и, в некотором смысле, правильный процесс. Вслед за сложностью растет и время, требуемое на изучение и подготовку, а значит времени остается меньше на изучение всяких других полезных и интересных тем. Мне грустно от того, что такие очевидные вещи приходится расписывать. Времена "мастеров на все руки" прошли. Вы можете в одиночку сделать кирпич, но не можете построить небоскреб.
Вы пишите: "глубокая специализация начинает тормозить IT-производство" - это просто вранье. Наоборот, процессы распараллеливаются, все ускоряется. История это доказывает: продуктов больше, релизы чаще, готовые решения на любой вкус - вот что Я вижу вокруг.
Эта проблема - просто Ваша выдумка чтобы оправдать очередное бессмысленное словоблудие, стандартизацию стандартов, спецификацию спецификаций, стандартизацию спецификаций и прочий эффективный менеджмент.T-shaped культура и прочая чушь пригодна только для "соевых инженеров", бегающих по конференциям про одно и то же, и бесконечно цитирующих одну и ту же книгу, но с других требующих T-shaped компетенций и разбираться во всем на свете. Попробуйте почитать Таненбаума или Кнута - там 7 томов, а не 400 страничек, как у Эванса. Нужны годы чтобы освоить это в совершенстве. Или это только программисты\инженеры должны прочитать и Кнута и Эванса, а великим "стандартизаторам" можно обойтись чем-то одним?
Выше уже замечали, но я не могу обойти этот вопрос стороной. Что такое "Ответственность", о которой Вы пишете, для наемного программиста? Я понимаю, что такое ответственность для владельца - ты принял плохое решение, ты потерял деньги, принял хорошее - получил. А для наемного работника это как? Будете делиться прибылью пропорционально успеху компании или это просто красивые слова и очередная брехология?
Что касается стандартизации, с одной стороны у вас стандарты стандартизации, а с другой Вы пишете про "Выход за рамки", "Инициативность" и "Развитие". Вам не кажется что одно слегка противоречит другому, а истинное "Значение стандартизации" = 0?
Вы пишите: "давайте уже избавимся от образа разработчика как какой-то «биомашины»", но тут же пытаетесь навязать им(нам\мне) какие-то стандарты работы, как у Вас уживается в голове это противоречие? Я - уже не биомашина, от того, попытка надеть на мою сферу очередные "стандартизации" вызывает у меня (и судя по комментариям - не только у меня) некоторое негодование.
Что касается ChatGPT, когда Вы говорите молодым сотрудникам: "скоро тебя заменит какой-нибудь ChatGPT" - это ложь и манипуляция. С самого начала карьеры я слушаю как меня заменит более сильный прогер или более молодой, или теперь ChatGPT. Только вот, как показывает эта статья, любители заменять программистов не способны даже статью без противоречий написать, не то что ТЗ для человека. А уж требования для GPT должны быть еще более проработанными.
Вы говорите о "Коммуникации", но это работает в обе стороны. Почему только прогер должен "общаться с бизнесом, общаться с коллегами", а не наоборот? Может было бы лучше, если бы и со стороны бизнеса было умение общаться с программистами? Интерфейс известен: Техническое задание. Ах да, без прогера же никто не способен его составить (иначе зачем Вы предлагаете разработчикам заниматься и аналитикой?).
В заключении, пока разработчик, или как вы в унизительном ключе выражаетесь, кодер, не напишет код, все ваши потуги бессмысленны. Идея же заставить программиста и анализ провести, и аналитику и ТЗ себе написать, сделать самому, и потестировать еще - не нова. И не полезна. Вы пишите, что скучаете по тому, как было раньше (раньше было лучше, да?). Это буквально анти-развитие и анти-прогресс. Не надо так.
Мой перфекционизм заставляет задать вопрос: Как вы выбираете между "вы пи́шете" и "вы пиши́те", подразумевая свершившееся действие адресата? У вас в комментарии и так, и эдак.
Везде только первый вариант
По контексту можно предположить значение слова
Словоформы соседних слов иногда могут развеять двусмысленность
UPD: Я тут со второго раза понял, о чем Вы. Вероятно дело в моей дислексии, эмоциональном напряжении в момент написания комментария, а так в же чрезмерном доверии встроенной проверке орфографии. Ответ на вопрос: похоже выбирает рандом.
Поддержу автора, т.к. сам работаю в режиме "и на дуде игрец", и действительно участие на всех участках и этапах проекта позволяет экономить время в поисках ответа на вопрос: "а что же реально надо заказчику?" и "как попроще и побыстрее это реализовать?". Но такой подход идеален для команды из одного человека и, возможно, применим для небольшой команды. Минусы очевидны: 1) Большие проекты не потянуть по срокам. 2) Каждый специалист такой команды трудно заменим, потому что он уже не "винтик" в системе. 3) Сейчас, наверное трудно найти или вырастить с нуля таких специалистов , потому что даже для узкой специализации нужно много чего освоить, а для широкой специализации нужно и желание и время и интерес. 4) Сейчас не в тренде искренне переживать за работу на дядю как за свое личное дело (а именно это требуется для эффективности), так что переубедить людей будет непросто. )
Сейчас, наверное трудно найти или вырастить с нуля таких специалистов
По идее так и идёт карьерный рост - джун пишет код по чёткой спецификации, миддл проектирует и пишет код (делегируя часть работы другим) по спецификации фичи, видимой для пользователя, сеньор предлагает новые фичи, делающие продукт лучше для пользователя и участвует в их реализации. Соответственно, постепенно возрастает важность понимания предметной области. Если человек хочет и может расти - никто не мешает общаться с более сеньорными людьми.
сам работаю в режиме "и на дуде игрец", и действительно
был както интерактивный выпуск эфира на общественном телевидении про выгорание и задачи не по вакансии - отправил ведущим в эфир смс: приходишь к рабoтадателю с растроением личности а уходишь уже с десятком ... как оживилсь ведущие да прочитали в эфир смс
Разработчики хотят оставаться в своих узких «клетках», концентрируясь на собственных скиллах и не желая расширять кругозор.
Вот только выше вероятность, что в один непрекрасный момент скиллов разработчика недостаточно для какой-либо задачи, а потом и вовсе могут "выставить на мороз".
И вообще, впечатление от статьи, будто кто-то пытается переложить свою работу и риски своей должности на других.
«Разработчик должен понимать смысл того, что он пишет»?
Спасибо, Кэп :-D Мы-то и не знали :) Научите из 8 слов сделать целую публикацию, а?
Хотя нет, не надо :-D
Нужно иное! Нам не хватает правильного стандарта разработки, чтобы мы могли эффективно работать и при этом нам не требовалось бы много времени на погружение в него.
так он уже есть!
Бизнес-аналитики ставят задачу, а дальше начинают работать системные аналитики, которые анализируют систему и архитектуру, прорабатывая это решение… А всё это время разработчики сложили лапки и сидят, ждут, когда до них доползёт эта задача
вот, отлично ж описана классическая галлерная схема, которая низводит разраба до интерпретатора разжеванной до мелочей задачи в исходный код, и, да, не ожидающая от кодера ни погружения, ни ума выше среднего, еще и контроль какой серьезным людям дающая!
к первой картинке: видел в 2012 программиста php у которого за 15 лет работы закончилсаь вторая трудовая да в неё уже вкладыши закончились - перед этим видел с аналогичным стажем химика да у него весь период обучения в стаже и потом переводами между конторами одной корп забита трудовая ... меня в этом году за 10 лет впервые уволили (за прогулы) и я перелеснув страницу понял что закончилась айти-трудовая да я больше никуда не устраивался да сжёг её десять лет назад - а вы говорите php
Адам Смит в гробу перевернулся. Тут бы найти разраба, который хотя бы код будет писать так, чтобы не пришлось переделывать, а вы так далеко замахнулись...
Я сам стараюсь быть таким разработчиком-инженером (крафтсменом), но для подавляющегг большинства людей это недосягаемая вершина и прямой путь к выгоранию. Ранок уже давно решил как выгоднее и я бы не стал идти против него.
На самом деле никакой проблемы нет - просто поднимите зп разрабам в 1.5-2 раза и к вам подтянуться такие люди. Но нет же, нужно написать свой стандарт, придумать очередную "гениальную" идею, которая всех спасёт.
Рынок заказной разработки, имхо, наоборот решил идти по формату описанному в посте
сам в заказной разработке и там как раз готовы поднимать зп/делиться с % (хоть и небольшим) от прибыли, но пусть люди горят продуктом как сам бизнес и не работать как описано в посте «заказчик-аналитик-аналитик-разраб-тестер»
Почти что процитирую из опыта коммуникации с заказчиком внешним после небольшого инцидента на проде (упрощенно и вульгарно моими словами): да мне пофиг на чьей стороне проблема, фронт или бэк, пусть хоть ПМ ваш исправляет ее - плачу за то, чтобы продукт рос, а не вы тут в проект и всякие флоу игрались
О! Веб-мастера возрождаются :) помню, такое было слово до этих ваших фронт/бэк/девопсов.
Все что Вы описали, тем и занимались веб мастера. Единственное отличие - это то что из статей было… а ничего особо и не было, кроме документации, написанной на коленке самими разработчиками. Как-то раз, изучал BGP, чтобы настраивать циску.. собственно оттуда и пример. На весь доступный интернет была только одна страница с документацией по BGP. Так и росли простые веб мастера. Это было в 2005 или 2004.. не помню точно:)
Ага
Выше про это же вспомнил:)
Я кншн тогда еще юный был, но кажется тогда пожеще были старшие товарищи, иначе сегодня ни гугла ни яндекса бы не было (ведь в 80е каждый текущий узкий спец хоть немного да варился в смежных темах и понимал с кем работает)
Ну и пример зачем фронту знать как устроен бэк: «а давайте все подсчеты переведем на бэк, а то не хотим получать список курсов валют за раз в 30валютах и при смене базовой валюты самим считать математически, а то вдруг там погрешности..» - так а ничего, что бэк будет заниматься обслуживаемым неумелого фронта и загибаться от мусорных запросов из-за каждого клика юзера вместо реально важной обработки данных?
На самом деле здесь статья не про кодера и программиста, а автор поднимает проблему взаимодействия людей в большой компании. Думаю, автор не понял в чем проблема и поставил неверный диагноз. Тут не кодеры плохие, поэтому давайте их переучим на инженеров. Тут проблема в эффективной коммуникации между различными отделами. Решение этой проблемы в митингах, когда собирается группа людей из разных отделов и вместе решают целую цепочку, как будет выполнен проект от начальной стадии, до готового результата, который хотел бы видеть клиент. Когда каждый выскажется, как он видит конечный продукт или то как он видит выполнение своей узкоспециализированной задачи, дает каждому из команды общее представление, для чего нужен продукт, что бы все хотели получить в конечно итоге. Каждый должен выдать свою "экспертную оценку" в своей сфере деятельности, а проджект менеджер, тим лид, должен скоординировать всех для получение "адекватного" конечного результата. Вот и вся проблема.
Не про кодера и программиста, соглашусь - про мышление и инженерную культуту, как мне видится. Про общее видение и одинаковое понимание результата. Может тут кто-то помнит, была такая миниатюра Аркадия Райкина про костюмчик, который криво сидит: "к пуговицам претензии есть? - нет, пришиты намертво, не оторвешь". Очень мой дедушка любил Райкина, и цитировал его мне. Так вот очень соответствует эта картинка тому, о чем говорит автор поста.
Согласен
почему-то я ее так и прочитал (исказил в своей больной голове), отчего и поддерживаю уже в N-м комменте автора, хоть и ключевой субъект статьи указан «разраб» или «программист»
Кмк речь и шла про всех участников всего цикла разработки продукта (кстати в таком ключе пост вроде можно проецировать не только на айти, а на многие сферы разработки, где нет конвеерного/монотонного труда, т.к. там нужны больше исполнители, имхо, а вот разработчики этого конвеера - не разрабы - вот к ним, думаю, можно применить эту же статью)
У меня больше 15 лет стажа. Сейчас могу создать почти любой продукт с нуля. В том числе работая за дизайнера и верстальщика, но за эту работу буду требовать в 10 раз больше денег, потому что - ну его нафиг. Тратить время на согласование дизайна, а потом вверстку css и скрипты js?! Нет!
Каждый должен заниматься тем, от чего его прет.
В том числе работая за дизайнера и верстальщика
Я понял статью по другому - важно понимать задачу в целом, но не обязательно всё делать самому. То есть, скажем, при добавлении поддержки какой-нибудь новой инструкции процессора в компилятор - не просто вставить в кодогенератор её выдачу для какого то паттерна в промежуточном представлении, но и убедиться, что она реально может сгенерироваться из исходного кода, а лучше - выяснить, как обычно люди пишут код, который можно оптимизировать с помощью этой инструкции и сделать так, чтобы она генерировалась в таких случаях. Но если для этого нужны изменения в фронтенде для разных входных языков - специалист по кодогенерации не обязан делать их сам, можно делегировать работу соответствующим людям.
Всегда считал, что в компетенцию программиста входит весь жизненный цикл ПО от постановки задачи до внедрения и сопровождения. Крупные компании могут позволить создавать команды-конвейеры, в которых у работников узкие роли. Так и появились кодеры, математики-алгоритмисты, тестеры... В мелкой компании человек может исполнять все роли. Т.е. составить ТЗ, реализовать, а потом развернуть. И это не значит что у человека будет больше нагрузка. Наоборот может быть из-за небольшой нагрузки он может тянуть все и больше людей брать не нужно. Проблема большой нагрузки не связана с ролями, это отдельная проблема как и токсичный коллектив или плохой микроклимат(не топят на складе)
Если человек прошел курсы, то он может не владеть всем набором ролей, но вполне вписываться в конвейер.
Я думаю программисту важно какой опыт он получит. Ему важно развиваться в одной области глубоко или хочется большей универсальности.
Отдельно хотелось бы сказать про ТЗ. Очень плохо если программист не выходит в поле. Хотя бы в начале проект нужно побывать у заказчика и своими глазами увидеть контекст. Если посредственный системный аналитик(а о таких я часто слышу), то формируется испорченный телефон и разрабатывается не то что нужно. Бюрократическая поделка. По бумагам все правильно, но пользоваться невозможно. У автора есть похожее про это, но не совсем то. Он хочет больше доить.
Всегда считал, что в компетенцию программиста входит весь жизненный цикл ПО от постановки задачи до внедрения и сопровождения.
Верное утверждение вот только стоит уточнить что все это делается только с технической стороны.
Крупные компании могут позволить создавать команды-конвейеры, в которых у работников узкие роли. Так и появились кодеры, математики-алгоритмисты, тестеры...
Они разделились не поэтому а потому что само по себе ПО стало намного сложнее и больше и один человек уже не может все это выполнять потому что сроки явно будут совсем другими. Когда-то средним проектом считался клиент банка и то из-за реализации модулей безопасности, сейчас клиент банка это мультиплатформенный клиент в котором можно и билеты на театр заказать и на самолет с синхронизацией между разными устройствами, а в последнее время еще и AI ассистентом. Если раньше клиентом банка мог действительно заниматься один программист то теперь как считаете все еще может?
В мелкой компании человек может исполнять все роли. Т.е. составить ТЗ, реализовать, а потом развернуть. И это не значит что у человека будет больше нагрузка. Наоборот может быть из-за небольшой нагрузки он может тянуть все и больше людей брать не нужно.
Нагрузка тут не причем, размер и сложность проекта на это влияют.
Очень плохо если программист не выходит в поле. Хотя бы в начале проект нужно побывать у заказчика и своими глазами увидеть контекст.
В большом количестве случаев это невозможно или даже бесполезно. Например Вы делаете систему для автоматизации больницы, Вы приехали в больницу и что Вы там узнали? Чтобы получить полный контекст чего-то Вам надо задержаться там надолго и "поработать" вместе с заказчиками. Но опять же даже если Вы побываете там в начале проекта это не гарантирует того что на объекте что-то поменяется через полгода или год когда проект уже будет на финальных стадия разработки. Именно поэтому есть аналитик который должен "кататься" часто к клиенту чтобы следить что там у него происходит.
Вам надо задержаться там надолго и "поработать" вместе с заказчиками
На прошлой работе такое называлось "dungeon" - когда представители заказчика, ключевые девелоперы (и, конечно, специально обученные люди, которые и так постоянно с заказчиком контактируют) собираются на недельку и вместе разбирают работу продукта на реальных задачах. Конечно, такое было только с крупными клиентами.
И все это за примерно $1-1.5тыс. долларов в месяц, автору бы купить пару губозакаточных машинок, одной недостаточно будет.
Я изнутри понимаю о чем пишет автор, и видимо он не смог сформулировать свои мысли так, чтобы вызвать положительную реакцию у читающего сообщества. В его поддержку хотелось бы сказать, что он на самом деле именно разработчик, а не "эффективный менеджер", и желание иметь вокруг себя разносторонних инженеров, а не простых кодеров-исполнителей, тоже вполне рациональное и на мой взгляд естественное.
Но как по мне, то даже если собрать под свое крыло только высококлассных инженеров (на самом деле их и так в газпромбанке немало), всё равно чуда не произойдёт. Проблема эффективности ведения разработок внутри большой распределенной компании с огромным количеством разнообразных, сильно связанных сервисов, не в количестве квалифицированных специалистов и не в отсутствии всеобъемлющего стандарта на все случаи жизни, а в налаживании кропотливой работы по постепенному улучшению множества различных процессов. И Agile тут совсем не та таблетка которая может что-то изменить.
А вот как это всё работает на практике в Газпромбанке.
Ответственность и полномочия по максимуму размазываются на участников команды: аналитиков, разработчиков, тестировщиков. За счет этого сокращаются важные и нужные позиции: проджект-менеджер, тимлид, выделенные архитекторы, все их функции спускаются на команду. Это всё активно пропагандируется руководством и департаментом Agile, если не согласен - то ты не инженер будущего, а просто кодер, которые не хочет тишейпиться и приносить пользу команде. Приносит ли это какой-то эффект кроме выгорания сотрудников, нужно ли это вообще командам, никто не задумывается.
В банке есть и примеры команд будущего, где аналитики работают очень посредственно, зато работают разработчики-инженеры, а не тупые кодеры. Внятной документации нет, на все вопросы ответ ищет разработчик в коде. Это ведет к куче багов и проблем, из-за которых страдают связанные команды.
Отдельная проблема возникает, когда аналитику нужно узнать, как работает такая система. Вместо чтения документации он вынужден тратить время на созвоны, чтобы разработчик посмотрел код и рассказал, как работает эта система. Конечно, нормально в такой ситуации ничего понять невозможно, что снова ведет к недопониманиям и багам.
На вопрос, надо ли идти работать в Газпромбанк, ответ такой: будьте готовы к насаждению такой культуры и только на зарплату выше рыночной, пока такая возможность есть. В идеале вообще сидеть не париться и получать деньги, иначе вашей ответственностью будут злоупотреблять.
С другой стороны - это не первая команда цифровой трансформации, вполне вероятен вариант, что снова придет другая, скажет, что всё это чушь и будет пропагандировать четкое разделение ролей.
Интересный поинт про результат такого решения как выгорание - согласен с этим
Но кажется тут не хватает как раз таки налаженности процессов и прозрачности системы, чтобы люди понимали ради чего оно все, зачастую тяжелый день это тяжелый день, но вот если он тяжелый и бессмысленный, а не «ля как тяжело, но я знаю ради чего и какой крутой результат получился» - то это, кмк, приводит к дизморали и дальше путь 1 - выгорание
з.ы. Да есть кучу других поинтов про выгорание, но думаю в рамках топика это 1 из основных
Выгорание и дизмораль сейчас случаются как раз из-за того, что рядовые сотрудники не понимают, почему они должны делать чужую работу. Позиции сокращаются, обязанности размазываются только ради того, чтобы банк сэкономил денег (оптимизация) и оправдывал придуманный непонятно кем и зачем подход (или слизанный у других организаций без адаптации к текущей). Это вызывает недоумение, потому что некоторые роли крайне важны и в других организациях они присутствуют.
Возможно, в какой-то одной команде это и сработало из-за их специфики. Я тоже работал в маленьких командах (ПО и по одному аналитику, фронту, бэку, QA) без больших внешних зависимостей. Но нельзя такую практику распространять на весь банк, не вникая в проблемы команд. А это как раз и происходит.
Объяснение типа "вы должны быть инженерами, а не просто кодерами", конечно, никого не устраивает и мотивации не добавляет. Никто не спорит, что любой специалист высокого уровня должен быть вдумчивым, не усложнять, не перекладывать ответственность на других и т.д. Но к этим очевидным пунктам подмешивается навязывание чужих обязанностей (кстати, за эти обязанности никто не доплачивает, зарплата выбивается отдельно).
Увы, вся эта практика насаживается в приказном порядке без учета потребностей команд. Аджайл и руководство слились в едином порыве и рисуют красивые презентации, графики, статьи в блогах и описания вакансий.
Потому люди внутри и недовольны. Снаружи, как видно по комментариям здесь, тоже. И зачем идти человеку в банк, изначально понимая, что на него будут вешать чужую работу, не очень понятно. Кроме, конечно, зарплаты выше рынка.
Да, абсолютно верно про то, как именно это внедряется (криво/по приказу/не адатированно)
Но моя политика такова:
если тебе интересна и приятна твоя работа без этого требования, ты и так начнешь приходить в подобный формат (мб это только у меня так в голове работает)
Если же тебе ок и так, но «новые правила про инженеров» не устраивают, ибо «сверх ДО за те же деньги» - я включаю правило «утром стулья, вечером деньги», сначала делаю новые ДО, набираю опыта и дпльше иду с фактами/числами договориться о повышении + сразу строим план на след.период с новым пулом задач до след.встречи с руководителем о возможном повышении
С моей колокольни системного аналитика могу заявить, что СА в современной разработке ПО не нужны. Системным анализом и проектированием ПО (software engineering) должен заниматься инженер-программист.
СА выступает в качестве эдакого секретаря разрабов занимаясь разговорами с бизнесом выявляя требования и передавая их разрабам, потому что бизнес, видели не может понятно донести до разрабов свои требования, а у разрабов не хватает ума задать правильные вопросы
СА проектирует систему и передает ее разрабам чтобы закодили. Тут дело в том, что в большинстве случаев разраб уровня мидл и выше технически более компетентен чем СА и сам в состоянии спроектировать систему и закодить ее.
СА нет места в (SAFe) agile-командах. Agile - это про дух стартапа, когда 6-7 челов с одной идеей, примерно одним бэкграундом сами пилят свой продукт-единорог. Они сами понимают что нужно пользователю, как закодить, как протестировать и довести продукт до пользователя. Они там все T-shaped, вовлечены и мотивированы и, главное, самостоятельны (такие вообще есть?). SAFe - это когда, опуская нюансы, таких команд много. Тут нет этапа системного анализа системным аналитиком. Но в компаниях, где проходила "agile-трансформация", СА по-прежнему есть.
Тут еще можно много частностей и холиварных пунктов привести, но это тема для отдельного исследования.
СА нужны, например, когда у вас жесткий waterfall, госзаказы, оборонка, когда суперсложные системы, когда их надо сначала долго и мучительно проектировать и потом с первого раза сделать. Т.е. это не про гибкость, скорость и time to market.
Так что, имхо, часть компетенций, связанную с системным анализом, для будущего T-shaped разработчика можно смело отдать (точнее, вернуть).
А какие роли вообще нужны в команде, если всё можно отдать разработчику?
Ну, во-первых, пока сказал только за СА. Пока писал, задался этим же вопросом и не думаю, что разрабам можно отдать все - product owner, QA, техписы наверное должны в случае необходимости быть и обеспечивать вектор развития и качество продукта.
А, во-вторых - можно найти реальные примеры того, как продукт был создан одним разработчиком или провести мысленный эксперимент - сможет ли один разраб (или неколько) создать успешный/ полезный продукт без продакта, аналитика и прочих ролей и довести его до пользователей и сможет ли это же сделать другая роль в команде.
Вообще понятию ролей отводится слишком много внимания, вплоть до того что крупные компании пишут на них отдельные должностные инструкции и начинается игра в "не мой огород". Если речь идёт о стартапе и 6-7 человек ваяющих свой единорог, то там роли рождаются сами собой, в соответствии с наборами компетенций членов команды. А вот в крупных компаниях с кучей взаимосвязанных продуктов, основная проблема как раз в том, что деление на команды сильно неоднозначно и рождается из кучи совершенно разных условий, причем в первую очередь исторически сложившихся.
На мой скромный 30+ лет в разработке опыт, гораздо важнее определяться с тем как лучше выделять зоны ответственности, формулировать задачи, определять критерии завершения и приоритеты, всё остальное хороший разработчик/команда разработчиков в состоянии сделать самостоятельно. И если у команды есть четкое понимание успешности, стабильности постоянно идущих процессов, то она будет улучшать свои показатели за счёт естественной природной лени.
Нам не нужны кодеры, нам нужны инженеры-разработчики