На данный момент не имею опыта работы в формате, что вы описали (мне дают тз и я делаю по нему/по своему), ко мне обращаются с обрывками контекста "хотим что-то" или "хотим вон как у тех ребят, ток с нашими фишками", а я уже занимаюсь погружением в предметку и далее реализацией того, что хотели (если упрощенно и по верхам сказать, кншн же, есть шаги обсуждения/согласования с заказчиком то ли он хотел увидеть)
Да, абсолютно верно про то, как именно это внедряется (криво/по приказу/не адатированно)
Но моя политика такова:
если тебе интересна и приятна твоя работа без этого требования, ты и так начнешь приходить в подобный формат (мб это только у меня так в голове работает)
Если же тебе ок и так, но «новые правила про инженеров» не устраивают, ибо «сверх ДО за те же деньги» - я включаю правило «утром стулья, вечером деньги», сначала делаю новые ДО, набираю опыта и дпльше иду с фактами/числами договориться о повышении + сразу строим план на след.период с новым пулом задач до след.встречи с руководителем о возможном повышении
Да, за пару тройку месяцев гуру уж точно не стать, но уж точно буду знать больше чем «джуны» в этом деле (например, чем начинающий менеджер в сфере клининга, для которого я бы и написал софт)
про t shaped шла же речь в посте, т.е. автор, как и я сам признается, что экспертом во всех сферах физически не стать, т.к. эксперты мы именно в разработке, но ввиду междисциплинарности профессии - надо не хуже джуна/мидла сферы, для которой пишешь ПО разбиратсья в предметке, иначе велика вероятность, что продукт будет сделан либо работает, но оч.кривой, либо сразу провальный, ибо делал тот, кто понятия не имеет что значит бизнес клининга
Интересный поинт про результат такого решения как выгорание - согласен с этим
Но кажется тут не хватает как раз таки налаженности процессов и прозрачности системы, чтобы люди понимали ради чего оно все, зачастую тяжелый день это тяжелый день, но вот если он тяжелый и бессмысленный, а не «ля как тяжело, но я знаю ради чего и какой крутой результат получился» - то это, кмк, приводит к дизморали и дальше путь 1 - выгорание
з.ы. Да есть кучу других поинтов про выгорание, но думаю в рамках топика это 1 из основных
почему-то я ее так и прочитал (исказил в своей больной голове), отчего и поддерживаю уже в N-м комменте автора, хоть и ключевой субъект статьи указан «разраб» или «программист»
Кмк речь и шла про всех участников всего цикла разработки продукта (кстати в таком ключе пост вроде можно проецировать не только на айти, а на многие сферы разработки, где нет конвеерного/монотонного труда, т.к. там нужны больше исполнители, имхо, а вот разработчики этого конвеера - не разрабы - вот к ним, думаю, можно применить эту же статью)
Я кншн тогда еще юный был, но кажется тогда пожеще были старшие товарищи, иначе сегодня ни гугла ни яндекса бы не было (ведь в 80е каждый текущий узкий спец хоть немного да варился в смежных темах и понимал с кем работает)
Ну и пример зачем фронту знать как устроен бэк: «а давайте все подсчеты переведем на бэк, а то не хотим получать список курсов валют за раз в 30валютах и при смене базовой валюты самим считать математически, а то вдруг там погрешности..» - так а ничего, что бэк будет заниматься обслуживаемым неумелого фронта и загибаться от мусорных запросов из-за каждого клика юзера вместо реально важной обработки данных?
Рынок заказной разработки, имхо, наоборот решил идти по формату описанному в посте
сам в заказной разработке и там как раз готовы поднимать зп/делиться с % (хоть и небольшим) от прибыли, но пусть люди горят продуктом как сам бизнес и не работать как описано в посте «заказчик-аналитик-аналитик-разраб-тестер»
Почти что процитирую из опыта коммуникации с заказчиком внешним после небольшого инцидента на проде (упрощенно и вульгарно моими словами): да мне пофиг на чьей стороне проблема, фронт или бэк, пусть хоть ПМ ваш исправляет ее - плачу за то, чтобы продукт рос, а не вы тут в проект и всякие флоу игрались
В заказной разработке и в финтехе та же проблема, что вы описали, но даже там можно +- применить большую часть идей из статьи
А что касается «сегодня мед.апп, чз 4 месяца соц.сеть» - наверно к счастью, но я и есть экземпляр этого человека, и да, я с каждой из областей разбираюсь попутно/заранее и если не к середине, то к концу разработки я уж точно необходимый минимум предметки освою (иначе уверен, что сделаю херню полную, а не проект)
З.ы. Как и автор выше в обсуждениях пишет - у меня та же история: большая команда, супер-апп (не горжусь за такое решение монструозного аппа, но заказная) со всем, что вокруг да около финтеха/соцсетей/adTech
Тоже разработчик и уж собирался коллегам выше подсветить, что всю свою карьеру (она недолгая еще, почти 5лет коммерческого и пару лет хобби до этого) так именно и считал и до сих пор считаю (да и при стартье ком.карьеры так меня-джуна учил мой наставник, с опытом в 10лет на тот момент уже)
Единственное, для меня странно, что это только сейчас стало актуальным (если правильно понял в тексте), кмк это в целом более зрелый подход и должно было быть изначально
Ну и 2 поинта вдобавок/подтверждение:
знать с кем работаешь - важно/нужно/полезно (это про «разбираться во всех процессах кто и где что делает)
Узкая специализация ведь тоже не самого начала была, она же пришла взамен исходной культуре «айти», когда бородатые дядьки все сами придумывали и воплощали, а там для масштабирования этого ремесла и начали дробить на более простые/узкие направление (пока писал вспомнил пословицу про сильные люди приносят хорошие времена, а хорошие времена порождают слабых людей… - будто это оно и есть, что возврат к истокам)
а если на этом же апи сидит и мобильный клиент (iOS/android app) - то уже не так просто, т.к. как автор сказал в статье - пользователь не пойдет обновлять аппку по нашему желанию
Нет, команда среднего размера
Я на бэке (кор команда) из 8 человек
Есть еще бэк команды поменьше и 3 фронт команды (по 1 на айос/андроид/веб)
Но так сложилось, что неспроста моя команда - кор, большую часть взаимодействия с заказчиком делаю я вместе с ПМ и аналитиком
На данный момент не имею опыта работы в формате, что вы описали (мне дают тз и я делаю по нему/по своему), ко мне обращаются с обрывками контекста "хотим что-то" или "хотим вон как у тех ребят, ток с нашими фишками", а я уже занимаюсь погружением в предметку и далее реализацией того, что хотели (если упрощенно и по верхам сказать, кншн же, есть шаги обсуждения/согласования с заказчиком то ли он хотел увидеть)
Да, абсолютно верно про то, как именно это внедряется (криво/по приказу/не адатированно)
Но моя политика такова:
если тебе интересна и приятна твоя работа без этого требования, ты и так начнешь приходить в подобный формат (мб это только у меня так в голове работает)
Если же тебе ок и так, но «новые правила про инженеров» не устраивают, ибо «сверх ДО за те же деньги» - я включаю правило «утром стулья, вечером деньги», сначала делаю новые ДО, набираю опыта и дпльше иду с фактами/числами договориться о повышении + сразу строим план на след.период с новым пулом задач до след.встречи с руководителем о возможном повышении
Да, за пару тройку месяцев гуру уж точно не стать, но уж точно буду знать больше чем «джуны» в этом деле (например, чем начинающий менеджер в сфере клининга, для которого я бы и написал софт)
про t shaped шла же речь в посте, т.е. автор, как и я сам признается, что экспертом во всех сферах физически не стать, т.к. эксперты мы именно в разработке, но ввиду междисциплинарности профессии - надо не хуже джуна/мидла сферы, для которой пишешь ПО разбиратсья в предметке, иначе велика вероятность, что продукт будет сделан либо работает, но оч.кривой, либо сразу провальный, ибо делал тот, кто понятия не имеет что значит бизнес клининга
Интересный поинт про результат такого решения как выгорание - согласен с этим
Но кажется тут не хватает как раз таки налаженности процессов и прозрачности системы, чтобы люди понимали ради чего оно все, зачастую тяжелый день это тяжелый день, но вот если он тяжелый и бессмысленный, а не «ля как тяжело, но я знаю ради чего и какой крутой результат получился» - то это, кмк, приводит к дизморали и дальше путь 1 - выгорание
з.ы. Да есть кучу других поинтов про выгорание, но думаю в рамках топика это 1 из основных
…и вот тут как раз, кажется надо 2й пост про то как именно у автора в компании/команде это делается
Т.к. вы верно подметили, чтобы такое организовать нужна самоотдача от всех причастных (и эффективные менеджеры и технари и бизнес)
Согласен
почему-то я ее так и прочитал (исказил в своей больной голове), отчего и поддерживаю уже в N-м комменте автора, хоть и ключевой субъект статьи указан «разраб» или «программист»
Кмк речь и шла про всех участников всего цикла разработки продукта (кстати в таком ключе пост вроде можно проецировать не только на айти, а на многие сферы разработки, где нет конвеерного/монотонного труда, т.к. там нужны больше исполнители, имхо, а вот разработчики этого конвеера - не разрабы - вот к ним, думаю, можно применить эту же статью)
Ага
Выше про это же вспомнил:)
Я кншн тогда еще юный был, но кажется тогда пожеще были старшие товарищи, иначе сегодня ни гугла ни яндекса бы не было (ведь в 80е каждый текущий узкий спец хоть немного да варился в смежных темах и понимал с кем работает)
Ну и пример зачем фронту знать как устроен бэк: «а давайте все подсчеты переведем на бэк, а то не хотим получать список курсов валют за раз в 30валютах и при смене базовой валюты самим считать математически, а то вдруг там погрешности..» - так а ничего, что бэк будет заниматься обслуживаемым неумелого фронта и загибаться от мусорных запросов из-за каждого клика юзера вместо реально важной обработки данных?
Рынок заказной разработки, имхо, наоборот решил идти по формату описанному в посте
сам в заказной разработке и там как раз готовы поднимать зп/делиться с % (хоть и небольшим) от прибыли, но пусть люди горят продуктом как сам бизнес и не работать как описано в посте «заказчик-аналитик-аналитик-разраб-тестер»
Почти что процитирую из опыта коммуникации с заказчиком внешним после небольшого инцидента на проде (упрощенно и вульгарно моими словами): да мне пофиг на чьей стороне проблема, фронт или бэк, пусть хоть ПМ ваш исправляет ее - плачу за то, чтобы продукт рос, а не вы тут в проект и всякие флоу игрались
В заказной разработке и в финтехе та же проблема, что вы описали, но даже там можно +- применить большую часть идей из статьи
А что касается «сегодня мед.апп, чз 4 месяца соц.сеть» - наверно к счастью, но я и есть экземпляр этого человека, и да, я с каждой из областей разбираюсь попутно/заранее и если не к середине, то к концу разработки я уж точно необходимый минимум предметки освою (иначе уверен, что сделаю херню полную, а не проект)
З.ы. Как и автор выше в обсуждениях пишет - у меня та же история: большая команда, супер-апп (не горжусь за такое решение монструозного аппа, но заказная) со всем, что вокруг да около финтеха/соцсетей/adTech
Тоже разработчик и уж собирался коллегам выше подсветить, что всю свою карьеру (она недолгая еще, почти 5лет коммерческого и пару лет хобби до этого) так именно и считал и до сих пор считаю (да и при стартье ком.карьеры так меня-джуна учил мой наставник, с опытом в 10лет на тот момент уже)
Единственное, для меня странно, что это только сейчас стало актуальным (если правильно понял в тексте), кмк это в целом более зрелый подход и должно было быть изначально
Ну и 2 поинта вдобавок/подтверждение:
знать с кем работаешь - важно/нужно/полезно (это про «разбираться во всех процессах кто и где что делает)
Узкая специализация ведь тоже не самого начала была, она же пришла взамен исходной культуре «айти», когда бородатые дядьки все сами придумывали и воплощали, а там для масштабирования этого ремесла и начали дробить на более простые/узкие направление (пока писал вспомнил пословицу про сильные люди приносят хорошие времена, а хорошие времена порождают слабых людей… - будто это оно и есть, что возврат к истокам)
а если на этом же апи сидит и мобильный клиент (iOS/android app) - то уже не так просто, т.к. как автор сказал в статье - пользователь не пойдет обновлять аппку по нашему желанию
но вопрос верный
Касательно энвов и именования - я б еще предложил всегда идти от общего к частному
т.е.
SETTINGS_API_ENDPOINT_AUTHвместоSETTINGS_AUTH_API_ENDPOINTДело, наверное, вкуса, но так при хранении разных энвов(кроме апи) в 1м месте по поиску найти все «нужные» проще будет