Ну и отработанный в «боевой обстановке» business continuity plan говорит о том, что нам стало все равно, откуда работать – хоть из Сочи, хоть из Оймякона — лишь бы связь была. Учитывая масштабы наших заказчиков и нас как федеральной компании, это очень важно. Хочется верить, что в перспективе этот опыт позволит работникам Solar JSOC пару дней в месяц работать из дома.
Несколько странно, что у компании федерального уровня всего этого не было до перехода на удаленку.
Работая, также, в компании федерального уровня могу сказать что у нас изначально налажена внутренняя IP телефония Cicsco и поверх телефона установлен Cisco Jabber и Cisco WebEx Meetings. И работать в распределенной команде, когда часть в Москве, часть в Питере, а часть в Екатеринбурге привычно и нормально даже в офисе.
Ситуация когда аналитик в Москве, а разработчик в Екатеринбурге вполне рядовая. Общение через видеозвонки с расшариванием экрана при необходимости тоже норма. Групповые встречи в формате видео конференции давно уже привычны.
С переходом на удаленку в этом плане ничего не поменялось — есть свой VPN сервер, есть персональные сертификаты, поверх VPN стоит тот же Cisco Jabber и все общение происходит ровно в том же формате. Ну разве что нет подключенного к компу IP телефона (собственно аппарата), но по большому счету он и в офисе не сильно нужен т.к. все звонки переведены на комп с использованием гарнитуры.
Есть проблемы с различными доступами к разным системам. Но это уже требования УИБ банка — VPN с персональными сертификатами позволяет не все, куда-то приходится ходить через удаленный рабочий стол на виртуалке с аутентификацией по индивидуальному софтверному токену (что, конечно, не сильно удобно). Но можно даже на свой рабочий комп выйти, хотя это совсем неудобно т.к. из Еката приходится сначала коннектиться удаленным рабочим столом к виртуалке в Мск, а с нее еще одним удаленным столом к рабочем машине обратно в Екате. Все это может тормозить и лагать порой. Но это далеко не всегда необходимо, в большинстве случаев оказывается достатчоно обычного VPN + удаленный рабочий стол до виртуалки (без коннекта на рабочий комп).
Россия отличается только тем (пока), что тут все очень прямолинейно. Бандит — это бандит. А не «бизнесмен». Ну и методы весьма прямолинейны. Взятка здесь называется взяткой, на «лоббированием» или «консультационными услугами».
Поверьте, есть некоторый опыт, достаточный чтобы понимать как делаются дела «там». Суть примерно одинаковая, но схемы куда более изощренные. Впрочем, наши тоже учатся.
Да где вы видели «разумный бизнес»… только в книжках. В реалиях взять любую контору что коммерческую, что гос.контору везде одно — получить максимум прибыли/плюшек при минимуме затрат.
Это нормально для бизнеса.
Другое дело, как определяется этот минимум. И что в этот минимум входит.
Если вы попали в бизнес, где к вам относятся как к расходному материалу… Ну не повезло. Но бывает и иначе. Возможно, дело еще в специализации разработчика и количестве претендентов на это место. Или в специализации бизнеса.
Ну тут от ситуации зависит. Где-то пройдет. Где-то нет.
Отмените проект, начнете планировать новый, а в это время конкуренты отхватят ваш кусок рынка. Иногда это приходится учитывать и быстрее выкатить заведомо более слабую версию просто чтобы закрепиться на рынке. А потом уже ее развивать.
У нас такое было когда пилили свой проект по системе мониторинга инженерного обрудования зданий.
Поначалу основная проблема была в том, чтобы убедить заказчика в том, что ему это нужно (начинали с нуля, ничего подобного не было тогда, но эта тема для отдельной статьи). Вплоть до того, что пилоты ставили за свои деньги просто с условием что эти объекты будем сами обслуживать.
Потом появились конкуренты. И там уже вопрос был кто первый застолбит поляну — если мы поставили свое обрудоваание и развернули свою систему, то клиент с нее уже так просто не соскочит — это не софт переставить, там куча оборудования монтировать нужно. И тут вопрос чато в том, кто первый успеет и предложит лучшие условия пусть и с меньшим функционалом (плюс «фьючерс» что будет новая версия с учетом хотелок клиента).
В тех условиях выход был только в жесткой фиксации ТЗ и соблюдении сроков поставки.
Сейчас тоже такое бывает — задачи идут валом, есть план. И если по какой-то из них заказчик вдруг начинает вертеть хвостом и менять хотелки, ему просто говорится — есть утвержденное BRD, работаем по нему. Хотите что-то еще — делаейте новую заявку на разработку и в очередь (BRD — оценка — FSD — разработка — тестирование — внедрение). Мы поставим в план и сделаем.
Очень, кстати, дисциплинирует, в том числе и заказчика. А то был случай когда с отчетом, который делается за неделю провозились два месяца (аналитик 4 раза ТЗ передалывал). Заказчик начал выделываться на бизнестесте — «а вот тут у нас три клиента в отчет не попадают, а нам кажется что должны попадать». Делаю полный трейслог, показываю — «у вас были сформулированы условия отбора клиентов, эти трое не проходят вот по таким параметрам». Заказчик «а давайте условия поменяем»… И начинается подгонка под ответ…
Вот такого надо избегать всеми силами.
Ну здесь даже с названия начинается — не «отдел кадров», а «департамент по управлению человеческим капиталом».
В одном из выступлений генеральный управляющий сказал что в условиях кризиса политика банка не только в сохранении своих кадров, но и в привлечении новых квалифицированных специалистов (из тех, кого вынужденно сократили в других местах).
Отчасти это еще связано со спецификой ИТ подразделений — готовых спецов в RPG и AS/400 в РФ очень мало (насколько я знаю, на этой платформе работает Альфа, Росбанк и Райф, ну может еще несколько контор вне финтеха). Т.е. в любого нового работника надо сначала вкладываться в обучение.
Естественно, что приветствуется проактивность и не приветствуется позиция «я человек маленький, хожу сюда за зарплатой».
Проактивность материально стимулируется — в прошлом году объявили повышение ФЗП на 5%. Конкретные цифры на усмотрение руководителей подразделений.
Позиция руководителей была такая — повысить всем на 5% скучно. Так что выбираем достойных и повышаем им. Без ложной скромности — мне повысили на 25% :-)
Плюс индивидуальные коэффициенты для рассчета годовых бонусов (базовый — 15% от годового оклада). Личный коэффициент по итогам работы может достигать 1.5. В целом это достаточно ощутимо в денежном выражении.
Т.е. с тебя требуют по максимуму, но и материально стимулируют если есть отдача.
При том, что никакой благотворительности нет и в помине. Ключевой вопрос — сколько на этом заработает банк. Просто разумный подход — схантить хорошего спеца, вложиться в него, простимулировать, получить отдачу. В результате всем хорошо и все довольны. Есть понятный вектор развития, есть четкие приоритеты, обязанности и ответственность.
Зато переобуться в воздухе в мелких конторах практически норма. А потом ты же виноват в срыве сроков проекта в котором ТЗ меняется быстрее чем ты успеваешь его реализовывать — «пока противник рисует карты, мы меняем рельеф местности».
Вообще, понимание что ТЗ должно быть намертво зафиксировано до начала разработки, а все свежие гениальные идеи должны откладываться в todo лист пришло достаточно давно. Даже для своих проектов.
Только так можно обеспечить сдачу проекта в срок без адских преодолений и бессонных ночей за монитором.
На самом деле тут проблема общая — взаимодействие работодателя и работника.
Я по образованию вовсе не итшник. Меня учили быть секретным физиком (да, в дипломе написано «Техническая физика» и номер специальности, а что за этим стоит уже знает тот, кому положено знать). Более того, если бы мне в институте, когда был курс «Основы вычтехники» сказали бы что я стану разработчиком, ни за что не поверил бы:-)
От распределения в какое-нибудь ЗАТО удалось открутиться, попал в один институт в система РАН. Продержался там 3.5 года, за которые понял что академическая наука не для меня. Отчасти из-за скотского отношения (характерного для всей системы РАН — много знакомых там работали или работают) — система чисто армейская — я начальник, ты дурак. Тебя могут грузить всем что попало. Ты аспирант или соискатель? Ну так тебе дисер нужен, давай работай. Нужно установку делать? Делай! Материалы, детали — все сам ищи. Нужен токарь? Найди. Заплати ему из своих («у института нет возможностей») — это ж тебе дисер нужен, у нас уже есть…
Опыт как не должно быть оказался очень познавательным. И полезым. Единственное, что отуда вынес — понимание что хочу заниматься программированием. Ну так получилось что пришлось заниматься обработкой данных, а толковых пакетов в те годы не было. Писал сам «Прикладной регрессионный анализ» Был настольной книгой и в значительной мере был перенесен в код.
Но все остальное довело практически до депрессии. Поэтому когда пришел знакомый и сказал «тут одна бизнесструктура создает коммерческую биржу и им нужны программисты» я просто пришел к начальству и сказал «вот заявление, хотите подписывайте, хотите нет, но с сзавтрашего дня меня тут не будет, за трудовой приду через месяц». Был, конечно, скандал, но это отдельная песня.
Дальше было много чего. В том числе и свой проект (по сути стартап, но тогда таких слов еще не знали), который подняли с нуля небольшими силами.
В конечном итоге, когда в последний раз менял работу, был выбор — мелкая конторка, которая занималась разработкой плагинов к системе архитектурного проектирования (плагины в основном направлены на осмечивание проекта и выгрузку данных в 1С). Удаленная работа, неплохие деньги, но… Полтора землекопа и полное отстутствие сколь бы то ни было внятной перспективы сколько это проживет и куда движется.
И тут в последний момент звонок из банка — давайте встретимся, поговорим. Пошел чисто ради интереса. Разговор получился очень доброжелательный — в теми людьми с которыми сейчас работаю. Рассказал чем занимался и что умею, мне рассказали что и как у них. И понял что ХОЧУ! Хочу тут работать. Несмотря на лютый легаси, кровавый энтерпрайз, несмотря на новый язык (RPG), абсолютно незнакомую платформу (IBM i, она же AS/400)…
Но тут настолько все четко организовано во всех отношениях. И отношения бизнес — разработка построены на взаимопонимании и стремлении к нахождению взаимоудовлетворяющих решений.
Ну и просто отношение к работнику как к активу, который нужно использовать с максимальной эффективностью (а это не только требования, но и создание условий). К примеру, на удаленку всех, кого можно, начали переводить еще до введения официальных карантинов. Просто чтобы минимизировать риски и сохранить квалифицированные кадры. Хотя это потребовало немалых вложений со стороны банка — организовать каналы связи и все доступы с учетом всех требований УИБ достаточно хлопотное занятие — сопровождение и поддержка в три смены работала.
В целом я сейчас вижу на собственном примере как все это должно быть в варианте близком к идеальному.
Ну здесь уже все упирается в то, куда ориентирован бизнес — получить сейчас побольше, а там трава не расти, или же обеспечить устойчивый рост пусть и с меньшей сиюминутной прибылью.
В конце концов, разработчик, когда идет на собеседование на новое место работы, тоже должен оценивать что его ждет — или ему обещают побольше денег, но видно, что в конторе нет нормально выстроенного workflow, когда все ТЗ будут формулироваться в стиле «сделайте нам красиво», причем в ходе работы (когда у тебя уже выстроена архитектура задачи) к тебе будут прибегать «а вот нам пришла еще гениальная идея — ее тоже надо как-то присрать к проекту» при том, что новая фича в архитектуру не вписывается от слова никак.
Или же денег вроде как поменьше, но есть четкая организация рабочего процесса, документирование на каждом этапе, четкое ведение задач и четкое разделение обязанностей и ответсвенности. И понимание того, что чтобы корова давал больше молока, за ней надо хорошо ухаживать.
Я лично выбираю второй вариант ибо за долгое годы в разработке шишек себе набил преизрядно и повидал многое.
И со всякими мелкими ООО «Сукин и Сын» предпочитаю не связываться — там нет перспективы. Если, конечно, это не твой личный проект где ты будешь работать больше ради того чтобы его поднять, а не только ради денег.
Возможно поэтому у меня не возникает вопросов должен программист решать проблемы бизнеса или нет — бизнес меня своими проблемами не грузит. Он формулирует задачи, которые я могу решить в рамках своей компетенции и создает мне условия для наиболее эффективного их решения.
Вот хуже нету когда нет ни ТЗ, ни документации по написанному коду. Тогда и возникают ситуации (описанные в одной их статей по этой теме) когда «никто кроме васи» не знает как и почему работает этот древний модуль.
Это случается достаточно часто. Но. Для бизнеса важно не знать как проблему решить, а уметь четко ее сформулировать. А остальное уже дело аналитиков и разработчиков.
У нас есть такой класс задач как оптимизация уже работающего кода. Выглядит это примерно так:
Бизнес: загрузка сервера в пике превышает 95%. Это проблема и с этим надо что-то делать.
Заметьте — в данном случае бизнес понятия не имеет как эту проблему решать. Но он ее четко формулировал.
Дальше в дело включаются специально обученные товарищи — аудиторы. Иногда свои из сопровождения, но обычно раз в год приглашаются специалисты из IBM (речь идет о серверах IBM i).
Они что-то там как-то измеряют, исследуют и выкатывают длинный список типа:
в модуле ххххх слишком часто производятся операции с датами что занимает 27% процессорного времени модуля.
в модуле уууууу при каждом запуске производится чтение из dtaara что занимает 18% процессорного времени
в модуле zzzzzz слишком много переоткрытий файлов, 36% процессорного времени
в модуле wwwww постоянно происходит формирование sql запроса на лету — 29% процессорного времени.
Дальше уже работа для разработчиков — каждый такой модуль рассматривается «под микроскопом» на предмет того что можно улучшить.
Потом тесты на неухудшение (сначала сравнеи результатов старой и новой версий, потом нагрузочнойе тестирование). Если все хорошо — внедрение.
Как-то так все это выглядит.
Задачи на оптимизацию даже не для всякого мидла — там требуется крепкое знание особенностей работы платформы, системных API. Иногда приходится часть модулей переписывать с RPG (основной язык) на С (более низкоуровневый по сравнению с RPG).
И это «внеплановые» задачи. Т.е. их надо как-то вклинивать в свой план так, чтобы основное не страдало.
Но это как раз тот пример, когда бизнес не может знать как решать проблему и отдает это на откуп специалистам.
Как правильно уже сказали — грейды ту не при чем. Грейды — это всего лишь тарифная сетка. Причем, она может перекрываться по минимальным-максимальным значениям и один человек с более высоким грейдом в деньгах может иметь столько же, сколько другой с более низким грейдом.
Так тимлид может занимать должность ведущего просто потому что в данный момент нет свободных должностей главного. Но по деньгам получать как главный.
А суть в том, что должно быть разделение обязанностей. Архитектор, аналитики, разработчики. Ну или всякие консультанты направлений, руководители направлений, аналитики, разработчики. И у каждого свой круг ответственности.
И поток сумеречного сознания бизнеса в первую очередь попадает на аналитика. Который вычленяет из него нечто разумное, отметает неразумное и вообще приходит к некоему консенсусу с заказчиком. На основе которого и рождается ТЗ для разработчиков.
У нас был такой проект — два электронщика (цифра и аналог), разработчик для миктроконтроллеров и два разработчика на верхнем уровне. И да, у нас был свой «архитектор». Который общался с заказчиками, обеспечивал общность направления движения всех разработчиков (и по железу и по софту). И никого не напрягало то, что полученные деньги надо делить на шестерых а не на пятерых.
Затраты на разработку не меняются — тут как договоришься с заказчиком, так и будет. А вот сумму делить на N+1 это да. Но эффективность разработки при этом тоже повышается. Просто потому что есть человек, который берет на себя массу «оргвопросов».
Разработчику этого должно быть достаточно. Но он также должен смотреть немного вперед и учитытьва различные «нефункциональные требования» к разрабатываемому продукту которые формируются исходя из простоты сопровождения, поддержки и дальнейшего развития продукта.
Да в общем даже банковский финтех на стороне бекэнда (по крайней мере) работает по схеме, которую я описал ниже. Там у разработчика основная задача в эффективной реализации потребностей бизнеса.
Даже вот эта задача habr.com/ru/post/501244/#comment_21595536 решается именно с точки зрения эффективности и рапределения приоритетов на уровне разработчика. Хотя, скажем, у нас, объем памяти на серверах исчисляется терабайтами (16 12-ядерных 8-поточных процессоров — 192 ядра, 1536 потоков, 2.5Тб ОЗУ на сервер), но эффективность все равно во краю угла т.к. в пике нагрузка может превышать 90%
Беда в том, что у вас изначально неправильно построены отношения. Если предположить ситуацию что есть:
1. Бизнес со своими потребностями
2. Аналитик
3. Разработчик
ТО все встает на свои места — бизнес формулирует хотелки (BRD, заявка на разработку), аналитик ее алгоримизирует (FSD, техзадание), разработчик воплощает ее в коде. Дальше в обратном порядке — аналитик тестирует на соответствие кода техзаданию, бизнес тестирует на соответствие результата своим хотелкам.
Каждый занимается своим делом. В такой схеме разработчик с бизнесом практически не общается. Только с аналитиком. Джуны и мидлы обычно просто пишут код по имеющемуся ТЗ, сеньоры могут принимать участие в разработке ТЗ с предложением использования тех или иных паттернов, оценке времени на выполнение и т.п.
Несколько странно, что у компании федерального уровня всего этого не было до перехода на удаленку.
Работая, также, в компании федерального уровня могу сказать что у нас изначально налажена внутренняя IP телефония Cicsco и поверх телефона установлен Cisco Jabber и Cisco WebEx Meetings. И работать в распределенной команде, когда часть в Москве, часть в Питере, а часть в Екатеринбурге привычно и нормально даже в офисе.
Ситуация когда аналитик в Москве, а разработчик в Екатеринбурге вполне рядовая. Общение через видеозвонки с расшариванием экрана при необходимости тоже норма. Групповые встречи в формате видео конференции давно уже привычны.
С переходом на удаленку в этом плане ничего не поменялось — есть свой VPN сервер, есть персональные сертификаты, поверх VPN стоит тот же Cisco Jabber и все общение происходит ровно в том же формате. Ну разве что нет подключенного к компу IP телефона (собственно аппарата), но по большому счету он и в офисе не сильно нужен т.к. все звонки переведены на комп с использованием гарнитуры.
Есть проблемы с различными доступами к разным системам. Но это уже требования УИБ банка — VPN с персональными сертификатами позволяет не все, куда-то приходится ходить через удаленный рабочий стол на виртуалке с аутентификацией по индивидуальному софтверному токену (что, конечно, не сильно удобно). Но можно даже на свой рабочий комп выйти, хотя это совсем неудобно т.к. из Еката приходится сначала коннектиться удаленным рабочим столом к виртуалке в Мск, а с нее еще одним удаленным столом к рабочем машине обратно в Екате. Все это может тормозить и лагать порой. Но это далеко не всегда необходимо, в большинстве случаев оказывается достатчоно обычного VPN + удаленный рабочий стол до виртуалки (без коннекта на рабочий комп).
Россия отличается только тем (пока), что тут все очень прямолинейно. Бандит — это бандит. А не «бизнесмен». Ну и методы весьма прямолинейны. Взятка здесь называется взяткой, на «лоббированием» или «консультационными услугами».
Поверьте, есть некоторый опыт, достаточный чтобы понимать как делаются дела «там». Суть примерно одинаковая, но схемы куда более изощренные. Впрочем, наши тоже учатся.
Это нормально для бизнеса.
Другое дело, как определяется этот минимум. И что в этот минимум входит.
Если вы попали в бизнес, где к вам относятся как к расходному материалу… Ну не повезло. Но бывает и иначе. Возможно, дело еще в специализации разработчика и количестве претендентов на это место. Или в специализации бизнеса.
Отмените проект, начнете планировать новый, а в это время конкуренты отхватят ваш кусок рынка. Иногда это приходится учитывать и быстрее выкатить заведомо более слабую версию просто чтобы закрепиться на рынке. А потом уже ее развивать.
У нас такое было когда пилили свой проект по системе мониторинга инженерного обрудования зданий.
Поначалу основная проблема была в том, чтобы убедить заказчика в том, что ему это нужно (начинали с нуля, ничего подобного не было тогда, но эта тема для отдельной статьи). Вплоть до того, что пилоты ставили за свои деньги просто с условием что эти объекты будем сами обслуживать.
Потом появились конкуренты. И там уже вопрос был кто первый застолбит поляну — если мы поставили свое обрудоваание и развернули свою систему, то клиент с нее уже так просто не соскочит — это не софт переставить, там куча оборудования монтировать нужно. И тут вопрос чато в том, кто первый успеет и предложит лучшие условия пусть и с меньшим функционалом (плюс «фьючерс» что будет новая версия с учетом хотелок клиента).
В тех условиях выход был только в жесткой фиксации ТЗ и соблюдении сроков поставки.
Сейчас тоже такое бывает — задачи идут валом, есть план. И если по какой-то из них заказчик вдруг начинает вертеть хвостом и менять хотелки, ему просто говорится — есть утвержденное BRD, работаем по нему. Хотите что-то еще — делаейте новую заявку на разработку и в очередь (BRD — оценка — FSD — разработка — тестирование — внедрение). Мы поставим в план и сделаем.
Очень, кстати, дисциплинирует, в том числе и заказчика. А то был случай когда с отчетом, который делается за неделю провозились два месяца (аналитик 4 раза ТЗ передалывал). Заказчик начал выделываться на бизнестесте — «а вот тут у нас три клиента в отчет не попадают, а нам кажется что должны попадать». Делаю полный трейслог, показываю — «у вас были сформулированы условия отбора клиентов, эти трое не проходят вот по таким параметрам». Заказчик «а давайте условия поменяем»… И начинается подгонка под ответ…
Вот такого надо избегать всеми силами.
В одном из выступлений генеральный управляющий сказал что в условиях кризиса политика банка не только в сохранении своих кадров, но и в привлечении новых квалифицированных специалистов (из тех, кого вынужденно сократили в других местах).
Отчасти это еще связано со спецификой ИТ подразделений — готовых спецов в RPG и AS/400 в РФ очень мало (насколько я знаю, на этой платформе работает Альфа, Росбанк и Райф, ну может еще несколько контор вне финтеха). Т.е. в любого нового работника надо сначала вкладываться в обучение.
Естественно, что приветствуется проактивность и не приветствуется позиция «я человек маленький, хожу сюда за зарплатой».
Проактивность материально стимулируется — в прошлом году объявили повышение ФЗП на 5%. Конкретные цифры на усмотрение руководителей подразделений.
Позиция руководителей была такая — повысить всем на 5% скучно. Так что выбираем достойных и повышаем им. Без ложной скромности — мне повысили на 25% :-)
Плюс индивидуальные коэффициенты для рассчета годовых бонусов (базовый — 15% от годового оклада). Личный коэффициент по итогам работы может достигать 1.5. В целом это достаточно ощутимо в денежном выражении.
Т.е. с тебя требуют по максимуму, но и материально стимулируют если есть отдача.
При том, что никакой благотворительности нет и в помине. Ключевой вопрос — сколько на этом заработает банк. Просто разумный подход — схантить хорошего спеца, вложиться в него, простимулировать, получить отдачу. В результате всем хорошо и все довольны. Есть понятный вектор развития, есть четкие приоритеты, обязанности и ответственность.
Зато переобуться в воздухе в мелких конторах практически норма. А потом ты же виноват в срыве сроков проекта в котором ТЗ меняется быстрее чем ты успеваешь его реализовывать — «пока противник рисует карты, мы меняем рельеф местности».
Вообще, понимание что ТЗ должно быть намертво зафиксировано до начала разработки, а все свежие гениальные идеи должны откладываться в todo лист пришло достаточно давно. Даже для своих проектов.
Только так можно обеспечить сдачу проекта в срок без адских преодолений и бессонных ночей за монитором.
Я по образованию вовсе не итшник. Меня учили быть секретным физиком (да, в дипломе написано «Техническая физика» и номер специальности, а что за этим стоит уже знает тот, кому положено знать). Более того, если бы мне в институте, когда был курс «Основы вычтехники» сказали бы что я стану разработчиком, ни за что не поверил бы:-)
От распределения в какое-нибудь ЗАТО удалось открутиться, попал в один институт в система РАН. Продержался там 3.5 года, за которые понял что академическая наука не для меня. Отчасти из-за скотского отношения (характерного для всей системы РАН — много знакомых там работали или работают) — система чисто армейская — я начальник, ты дурак. Тебя могут грузить всем что попало. Ты аспирант или соискатель? Ну так тебе дисер нужен, давай работай. Нужно установку делать? Делай! Материалы, детали — все сам ищи. Нужен токарь? Найди. Заплати ему из своих («у института нет возможностей») — это ж тебе дисер нужен, у нас уже есть…
Опыт как не должно быть оказался очень познавательным. И полезым. Единственное, что отуда вынес — понимание что хочу заниматься программированием. Ну так получилось что пришлось заниматься обработкой данных, а толковых пакетов в те годы не было. Писал сам «Прикладной регрессионный анализ» Был настольной книгой и в значительной мере был перенесен в код.
Но все остальное довело практически до депрессии. Поэтому когда пришел знакомый и сказал «тут одна бизнесструктура создает коммерческую биржу и им нужны программисты» я просто пришел к начальству и сказал «вот заявление, хотите подписывайте, хотите нет, но с сзавтрашего дня меня тут не будет, за трудовой приду через месяц». Был, конечно, скандал, но это отдельная песня.
Дальше было много чего. В том числе и свой проект (по сути стартап, но тогда таких слов еще не знали), который подняли с нуля небольшими силами.
В конечном итоге, когда в последний раз менял работу, был выбор — мелкая конторка, которая занималась разработкой плагинов к системе архитектурного проектирования (плагины в основном направлены на осмечивание проекта и выгрузку данных в 1С). Удаленная работа, неплохие деньги, но… Полтора землекопа и полное отстутствие сколь бы то ни было внятной перспективы сколько это проживет и куда движется.
И тут в последний момент звонок из банка — давайте встретимся, поговорим. Пошел чисто ради интереса. Разговор получился очень доброжелательный — в теми людьми с которыми сейчас работаю. Рассказал чем занимался и что умею, мне рассказали что и как у них. И понял что ХОЧУ! Хочу тут работать. Несмотря на лютый легаси, кровавый энтерпрайз, несмотря на новый язык (RPG), абсолютно незнакомую платформу (IBM i, она же AS/400)…
Но тут настолько все четко организовано во всех отношениях. И отношения бизнес — разработка построены на взаимопонимании и стремлении к нахождению взаимоудовлетворяющих решений.
Ну и просто отношение к работнику как к активу, который нужно использовать с максимальной эффективностью (а это не только требования, но и создание условий). К примеру, на удаленку всех, кого можно, начали переводить еще до введения официальных карантинов. Просто чтобы минимизировать риски и сохранить квалифицированные кадры. Хотя это потребовало немалых вложений со стороны банка — организовать каналы связи и все доступы с учетом всех требований УИБ достаточно хлопотное занятие — сопровождение и поддержка в три смены работала.
В целом я сейчас вижу на собственном примере как все это должно быть в варианте близком к идеальному.
В конце концов, разработчик, когда идет на собеседование на новое место работы, тоже должен оценивать что его ждет — или ему обещают побольше денег, но видно, что в конторе нет нормально выстроенного workflow, когда все ТЗ будут формулироваться в стиле «сделайте нам красиво», причем в ходе работы (когда у тебя уже выстроена архитектура задачи) к тебе будут прибегать «а вот нам пришла еще гениальная идея — ее тоже надо как-то присрать к проекту» при том, что новая фича в архитектуру не вписывается от слова никак.
Или же денег вроде как поменьше, но есть четкая организация рабочего процесса, документирование на каждом этапе, четкое ведение задач и четкое разделение обязанностей и ответсвенности. И понимание того, что чтобы корова давал больше молока, за ней надо хорошо ухаживать.
Я лично выбираю второй вариант ибо за долгое годы в разработке шишек себе набил преизрядно и повидал многое.
И со всякими мелкими ООО «Сукин и Сын» предпочитаю не связываться — там нет перспективы. Если, конечно, это не твой личный проект где ты будешь работать больше ради того чтобы его поднять, а не только ради денег.
Возможно поэтому у меня не возникает вопросов должен программист решать проблемы бизнеса или нет — бизнес меня своими проблемами не грузит. Он формулирует задачи, которые я могу решить в рамках своей компетенции и создает мне условия для наиболее эффективного их решения.
Это очень неправильный подход.
У нас есть такой класс задач как оптимизация уже работающего кода. Выглядит это примерно так:
Бизнес: загрузка сервера в пике превышает 95%. Это проблема и с этим надо что-то делать.
Заметьте — в данном случае бизнес понятия не имеет как эту проблему решать. Но он ее четко формулировал.
Дальше в дело включаются специально обученные товарищи — аудиторы. Иногда свои из сопровождения, но обычно раз в год приглашаются специалисты из IBM (речь идет о серверах IBM i).
Они что-то там как-то измеряют, исследуют и выкатывают длинный список типа:
в модуле ххххх слишком часто производятся операции с датами что занимает 27% процессорного времени модуля.
в модуле уууууу при каждом запуске производится чтение из dtaara что занимает 18% процессорного времени
в модуле zzzzzz слишком много переоткрытий файлов, 36% процессорного времени
в модуле wwwww постоянно происходит формирование sql запроса на лету — 29% процессорного времени.
Дальше уже работа для разработчиков — каждый такой модуль рассматривается «под микроскопом» на предмет того что можно улучшить.
Потом тесты на неухудшение (сначала сравнеи результатов старой и новой версий, потом нагрузочнойе тестирование). Если все хорошо — внедрение.
Как-то так все это выглядит.
Задачи на оптимизацию даже не для всякого мидла — там требуется крепкое знание особенностей работы платформы, системных API. Иногда приходится часть модулей переписывать с RPG (основной язык) на С (более низкоуровневый по сравнению с RPG).
И это «внеплановые» задачи. Т.е. их надо как-то вклинивать в свой план так, чтобы основное не страдало.
Но это как раз тот пример, когда бизнес не может знать как решать проблему и отдает это на откуп специалистам.
Так тимлид может занимать должность ведущего просто потому что в данный момент нет свободных должностей главного. Но по деньгам получать как главный.
А суть в том, что должно быть разделение обязанностей. Архитектор, аналитики, разработчики. Ну или всякие консультанты направлений, руководители направлений, аналитики, разработчики. И у каждого свой круг ответственности.
И поток сумеречного сознания бизнеса в первую очередь попадает на аналитика. Который вычленяет из него нечто разумное, отметает неразумное и вообще приходит к некоему консенсусу с заказчиком. На основе которого и рождается ТЗ для разработчиков.
Затраты на разработку не меняются — тут как договоришься с заказчиком, так и будет. А вот сумму делить на N+1 это да. Но эффективность разработки при этом тоже повышается. Просто потому что есть человек, который берет на себя массу «оргвопросов».
Первая задача решается аналитиком, вторая разработчиком.
Разработчик решает задачу. Это немножко другое.
Даже вот эта задача habr.com/ru/post/501244/#comment_21595536 решается именно с точки зрения эффективности и рапределения приоритетов на уровне разработчика. Хотя, скажем, у нас, объем памяти на серверах исчисляется терабайтами (16 12-ядерных 8-поточных процессоров — 192 ядра, 1536 потоков, 2.5Тб ОЗУ на сервер), но эффективность все равно во краю угла т.к. в пике нагрузка может превышать 90%
И эффективность это головная боль разработчика.
1. Бизнес со своими потребностями
2. Аналитик
3. Разработчик
ТО все встает на свои места — бизнес формулирует хотелки (BRD, заявка на разработку), аналитик ее алгоримизирует (FSD, техзадание), разработчик воплощает ее в коде. Дальше в обратном порядке — аналитик тестирует на соответствие кода техзаданию, бизнес тестирует на соответствие результата своим хотелкам.
Каждый занимается своим делом. В такой схеме разработчик с бизнесом практически не общается. Только с аналитиком. Джуны и мидлы обычно просто пишут код по имеющемуся ТЗ, сеньоры могут принимать участие в разработке ТЗ с предложением использования тех или иных паттернов, оценке времени на выполнение и т.п.