Когда я только пришел в мир IT, для меня, как и, наверняка, для вас, было много чего непонятного и неизученного. Это было мостиком моей мотивации, удерживающим меня в этой индустрии, но по мере того как ты завязываешь в узелок все свои накопленные знания, появляется уверенность в кое-какой стабильности, а следовательно — новый вопрос.
А что теперь?
Ну теперь вы, вроде, полноценный винтик среднего звена, так называемый middle developer, теперь хочется расти еще выше, в лиды --> архитекторы --> CTO.
А проблема на самом деле в том, что хоть сейчас у вас и есть уверенность в том, как писать какие-то функции, строить REST-приложения, но нет уверенности в том, правильно ли это делается с нуля, чист ли ваш код, как управлять другими разработчиками. Если вы задавались такими же вопросами или столкнулись с такой же проблемой, то в этой статье я постараюсь кратко описать некоторые вещи, которые помогли именно мне с этим разобраться.
Создайте систему
И это касается даже не сколько технической части — забудьте пока про код — создайте себе свод правил, по которым вы работаете. Помните: дьявол кроется в деталях.
Например, организуйте определенную инструкцию, как работать с Git, определенную систему ветвления по типу feature/bug/hotfix — название продукта в названии ветки; если таковых несколько, нужен отдельный стиль написания (camel case или snake). В Bitbucket, например, можно легко отфильтровать ветки, если в названии есть feature etc, таким образом можно быстро собрать статистику. Название ветки также намного важнее, чем описание коммита, так как всей команде совершенно очевидно, над какой задачей кто-то когда-то работал.
Помимо названий веток в гите можно много чего организовать сверху, например правила мерджа, ограничения на флаги, правила разрешении конфликтов, а чуть позже мы еще дойдем и до actions.
Далее выработайте стиль написания фитчей: здесь уже все в большей мере касается архитектуры проекта и, конечно, в первую очередь его простоты: все должно быть интуитивно понятно; изолируйте свою сущность в папку вместе с контроллерами, сервисами, репозиториями и прочими вещами, к ней относящимися. А после определите поэтапно, как разработчик должен писать фичу, начиная от создания ветки до pull request. Эту инструкцию расшарьте разработчикам и следите за четким её выполнением.
Представьте: вы собрали базу из предыдущих пунктов и что-то даже написали с командой.
А теперь пришел новый разработчик, он, конечно, со временем интегрируется в проект, но чтобы облегчить его задачу и команды в целом, опишите проект, создайте документацию: какие шаги требуются для запуска проекта и что надо предпринять для начала работы.
Постройте все лаконично и понятно: как работать с кастомными элементами на фронте, схемы о том, как работает ваш бэкенд, как и что с чем взаимодействует, если сервисы связаны и имеют комплексную логику. Используйте для этих целей нужные инстументы, которые уже есть в сети, потратьте чуточку вашего времени на их поиск. Я понимаю, что эти задачи кажутся пустяковыми на первых этапах проекта в сравнении с огромным количеством реальных задач, но такие вещи фундаментальны для работы проекта и для вашей личной комфортной работы как ведущего разработчика.
Работа над задачами
Четко организуйте работу с задачами, используйте такие инструменты, как Jira, Git Board, Notion и другие доски. Очень важно правильно организовать столбцы, правильно объяснить, когда, что и куда передвигается.
У вас столбцы могут иметь разные названия и смысл, но я для примера объясню на таких:
Analysis
To Do
Development
Block
Development Done
Testing
Testing Done
Production
На этом этапе вы можете пересечься с другими специалистами, такими как проджект менеджер или аналитик. Но помните о том, что доска — это инструмент для вашей работы, поэтому проследите, чтобы вам и вашей команде было комфортно. Особое внимание я бы уделил столбцу Block, в который задача попадает, когда на нее действуют внешние обстоятельства, независимые от разработчика.
Для того чтобы положить задачу в этот блок, надо объяснить обстоятельства, обозначить ответственного, если такой человек есть, отметить дату и время блока, что впоследствии может снять с разработчика ответственность и сохранить нервы вам, как ответственному за выполнения задач человеку.
Конечно, стоит обратить внимание на появление задач в бэклоге и их оценку, но это крайне обширная тема с индивидуальным подходом, поэтому я ограничусь парой советов:
Формирование задач менеджерами и их детальное описание.
Занесение задач в бэклог, когда они понятны любому программисту.
После этого задачи распределяются разработчикам в блок Analysis, они должны быть назначенными.
Все задачи, которые попали в блок Analysis, должны оценить разработчики, после чего — сместить их в блок To Do.
Разработчик смотрит на критичность задачи по приоритету и перетаскивает самые горячие из них в блок Development. Если приоритеты у всех задач одни, разработчик разбирает задачи по своему усмотрению.
Крайне важно дать разработчикам сразу несколько задач, чтобы они могли переключаться между ними по нужде или если их текущая задача попала в Block.
Задачи также могут быть связаны, поэтому разработчик может начать делать задачу 1, переключиться на задачу 2 и вернуться к задаче 1.
Programming, Analysis, Control
Программируй, Анализируй, Контролируй
Вы уже достаточно неплохо поработали над процессами; теперь, когда у вас есть система с инструкциями и конкретными действиями, время анализировать и контролировать. Конечно, ситуации разные, проекты и устройство компании разные, поэтому подстроить одну систему для всего невозможно, но возможно создать для нее базу. Когда она настроена, просто наблюдайте, собирайте проблемы и исправляйте их, вносите изменения, корректируйте вашу систему под себя.
Контроль качества
Ну а теперь дело за вашими техническими возможностями, софт-скилами ментора и умением работать в команде.
Когда задача завершена, разработчик должен открыть PR, а вы должны научить его работать в вашей системе. Я не говорю сейчас про оптимальность решения, но про стиль написания проекта, определенные правила кода, каким вы привыкли его видеть: простым, понятным, чистым.
Проверять PR необязательно обязаны вы, скорее это может быть человек, больше всего компетентный в том или ином участке кода.
Спойлер
Джуниор вы или лид — неважно. Начинайте внедрять в вашу работу улучшение процессов, и жизнь станет чуть легче.
Комментарии (89)
GospodinKolhoznik
16.01.2024 17:42-1Ну теперь вы, вроде, полноценный винтик среднего звена, так называемый middle developer...
А проблема на самом деле в том, что хоть сейчас у вас и есть уверенность в том, как писать какие-то функции, строить REST-приложения, но нет уверенности в том, правильно ли это делается с нуля, чист ли ваш код...
Как мне кажется полноценный бэкэнд милд в состоянии сделать продукт целиком (за исключением фронтенда и дизайна), а не просто уметь писать какие то функции и rest-api которое эти функции вызывает.
aleko855 Автор
16.01.2024 17:42Вы совершенно правы.
Когда я дорос до того, что был в состоянии сделать продукт целиком, всегда мелькала мысль, правильно ли я в действительности это делаю, вот почему я добавил это в статью.
GospodinKolhoznik
16.01.2024 17:42+1Ответ на ваш вопрос известен - всё делаете неправильно)) И я делаю неправильно, и все делают неправильно. Просто у кого то результат его неправильной деятельности работает, выполняет свой функционал и приносит прибыль (или пользу). А у кого-то код так и не доходит до состояния, когда он начинает работать.
lair
16.01.2024 17:42+2Как мне кажется полноценный бэкэнд милд в состоянии сделать продукт целиком
Что вы понимаете под продуктом?
GospodinKolhoznik
16.01.2024 17:42Под продуктом я понимаю всю систему. Для бэкэндера бэкэнд часть системы: бизнес логика системы + БД + взаимодействие с БД + API для GUI или фронтенда.
Конечно, я говорю про относительно простые системы, которых большинство. Про бэк для веб приложения, про внутреннее приложение для коммерческой организации, банка или промышленного предприятия.
Речь не идёт про разработку современной ОС, СУБД, продвинутого компилятора или продвинутого AI.
lair
16.01.2024 17:42Все еще не понятно. Вы когда говорите "вся система", вы имеете в виду сначала и до конца (то есть был пустой репозиторий, получили работающую систему), или все-таки добавление новой функциональности в существующую систему, в которой уже есть дизайн и какие-то основы, и надо просто что-то добавить?
Потому что для меня "продукт" - первое, а второе нынче принято называть "вертикальным срезом".
GospodinKolhoznik
16.01.2024 17:42Я говорю про продукт целиком. Ну по крайней мере за логику работы всего продукта целиком.
Ещё раз, я не говорю про сверхсложные продукты, такие как операционная система. Какую ни будь систему учета и автоматизации для коммерческого предприятия.
Ну, для конкретики в качестве примера могу привести, например систему учета грузоперевозок в логистической компании, куда заводятся данные какой водитель на каком грузовике в какой день куда ехал, что вёз, для какого клиента, сколько потратил топлива, чтобы система рассчитывала, сколько должен заплатить клиент и сколько надо заплатить водителю.
Это не высоконагруженное приложение, в нем нет никакого космоса в плане сложности. И как я себе представляю, полноценный мидл должен суметь справиться с написанием такой системы с нуля (с пустой репы) самостоятельно.
Конечно, при этом надо понимать, что человек мидл, а не синьер и уж тем более не рок звезда и ему на эту работу потребуется больше времени, чем более крутому специалисту.
lair
16.01.2024 17:42Я говорю про продукт целиком [...] Какую ни будь систему учета и автоматизации для коммерческого предприятия.
Не, в это я не верю. Я, так уж получилось, ровно в этой отрасли и работаю, и как только требования выходят за границы, грубо говоря, очень простого CRUD, миддлы уже не справляются с масштабами.
И как я себе представляю, полноценный мидл должен суметь справиться с написанием такой системы с нуля (с пустой репы) самостоятельно.
Пока речь идет про пару-тройку сценариев использования - да. Но как только это понадобится дальше расширять, он уже не справится.
GospodinKolhoznik
16.01.2024 17:42как только это понадобится дальше расширять, он уже не справится
Несомненно всё очень зависит от степени адекватности заказчиков и от частоты с которой заказчики фонтанируют идеями.
А ещё зависит от языка. Например на питоне или на жаваскрипт очень тяжело написать "устойчивый к изменениям код" даже для опытного разработчика. А вот на хаскеле наоборот, придерживаясь нескольких базовых принципов структурирования программы, удается добиться супер устойчивого к изменениям кода. На хаскеле обычному мидлу это вполне пол силу. Это достигается за счёт тотальной иммутабельности, отсутствия побочных эффектов, и самое главное за счёт referential transparency.
Джава где-то посередине. На ней можно написать устойчивый код, но это требует серьезной архитектурной организации и тщательного продумывания структуры всего приложения. А это действительно требует большого опыта от разработчика.
А вот на питоне даже супер сеньерский опыт не поможет)) я не знаю, как люди умудряются на питоне писать сложные приложения. Честно, я ими впечатлён. Я бы так не смог))
lair
16.01.2024 17:42Несомненно всё очень зависит от степени адекватности заказчиков и от частоты с которой заказчики фонтанируют идеями.
В первую очередь это зависит от масштабов системы.
На хаскеле обычному мидлу это вполне пол силу.
Я достаточно мало знаю про хаскель, но то, что я про него знаю, наводит меня на мысли, что мидл на хаскеле - это сениор и выше на мейнстримных языках. Что демонстрирует нам относительность этих оценок.
GospodinKolhoznik
16.01.2024 17:42мидл на хаскеле - это сениор и выше на мейнстримных языках
Всё же это немножко миф. Хаскель не такой сложный, как принято считать. Вся эта мифология возникла из за сложности понимания монад. Да, в изучении хаскеля есть реально сложное бутылочное горлышко, это монады, апликативы, и трансформеры монад. Но всё остально достаточно среднее по сложности. А с учётом того, что на освоение монад/апликативов/трансформеров суммарно уходит примерно месяц ежедневного изучения по 1-2 часа в день, то это ведь не очень долго. Ну а остальной язык учится довольно легко и приятно. Ну рекурсии много, ну и что? Да, вся логика на маппинге, фильтрах и свертках, так эти вещи уже во все языки перекочевали.
Я как то на реддите в хаскельном сообществе написал, что изучить джаву сложнее чем хаскель, т.к. в хаскеле надо сделать усилие по изучению монад, и этого достаточно, чтобы писать очень качественный код, а в джаве надо очень долго курить архитектурные приципы и шаблоны проектирования. И все пользователи там согласились со мной, что да, хасель проще джавы не один человек не возрожал.
lair
16.01.2024 17:42+1Всё же это немножко миф.
Это мое личное восприятие. Я не претендую на его объективность или генерализацию.
Я как то на реддите в хаскельном сообществе написал, что изучить джаву сложнее чем хаскель [...] И все пользователи там согласились со мной, что да, хасель проще джавы не один человек не возрожал.
Вы же это в хаскельном сообществе написали. Когда что-то освоено, оно регулярно кажется легким.
Lodinn
16.01.2024 17:42Позволю себе не согласиться.
Пример раз, поскучнее: продукт-перемалывалка данных. Можно хоть одиозный пример придумать: делаем сайт с гороскопами, с блэкджеком и ИИ, как нынче модно. Лох не мамонт, как говорится... И вот уже нарисовался "полноценный мидл": фулстек, ни в одной из компетенций звёзд не хватающий, но способный мануал прочитать и самостоятельно что-то сделать. Плюс запчасти друг с другом состыковать.
Пример два, поинтереснее: внутренний продукт для компании. Да, обычно за простеньким CRUD'ом таятся подводные камни: новые хотелки, неформализованные требования, специфика бизнеса. Но я бы лично поспорил, что вполне может быть сделан именно продукт, помогающий бизнесу. Иногда - понять, чего он хочет :) Нередко потом надо всё писать заново, но это может быть управленчески правильным шагом. Можно, конечно, сказать, что пока приходится вносить правки и фичи, это ещё не работающая система "под ключ", но тогда возникает вопрос - а что такое тогда готовая система? Хоть одна есть у того же Гугла, чтоб вот прям никто не тянулся улучшать?
В общем, классификация на "этот мидл, тот помидор" по-прежнему дурацкая, но для огромного количества далёких от айти контор, особенно мелких, не то что мидл нужен, а скорее "уверенный пользователь ПК", умеющий пользоваться поиском. Вплоть до того, чтобы найти, где купить и как настроить сервер с CMS-кой или конструктор лендингов.
Часто ещё бывает нужен программист "на штате": ТЗ сформулировать не могут/не хотят, поэтому вместо этого хотят поддержки продукта и за неё готовы платить. Знаю людей, которые окучат пару-тройку таких и горя не знают. На помидоров в серьёзном стеке не потянут, специализации не хватит. Зато задачи бизнеса решают чётко, "не то что эта молодёжь с питонами да гитами".
lair
16.01.2024 17:42Позволю себе не согласиться.
Не согласиться с чем конкретно? Вы не привели ни одного примера, который бы противоречил тому, что я сказал.
funca
16.01.2024 17:42Мне кажется продукт это то, что решает проблемы бизнеса. Софт здесь всегда лишь только часть - даже если вы продаете коробки. А в репозиториях лежат исходники приложения, или отдельных его компонентов. Написать работающее приложение и сделать прибыльный продукт это довольно разные вещи.
lair
16.01.2024 17:42+1...тогда выходит, что мидл на это тем более не способен
funca
16.01.2024 17:42+1Я согласен. Хотя, тут как всегда нужно учитывать контекст. Можно быть мидлом на конкретном проекте или даже в целой организации, закрывая таски. Но за рамками делать какие-то продукты. Образовательный курс, канал в соцсетях, музыкальную группу, школу танцев, магазин собранный по принципу no-code/low-code,... да хоть морковку в огороде выращивать и на рынке продавать (у меня есть живые примеры). :)
funca
16.01.2024 17:42+2Мидл это способность решать технические задачи без постоянного supervision снаружи. Взять на себя ответственность за подсистему или компонент, и генерировать такие задачи уже самому под контролем старших товарищей - это синьерский скилл.
ivankudryavtsev
16.01.2024 17:42теперь хочется расти еще выше, в лиды --> архитекторы --> CTO.
Это вообще не органичный, не всегда естественный и часто неоправданный смысл. Нужно расти в эксперта… и к чему душа лежит. Много платят и работа интересная у экспертов, а не у архитектора / CTO. К примеру, есть знакомый инженер в Армении, пишет на C++. Выставляет от $10 до $11k/мес. за услуги. Надо вот ему архитекторы, CTO?
aleko855 Автор
16.01.2024 17:42Конечно нет, я с вами полностью согласен, нужно расти в профессионала, но если это ваш случай, то надеюсь статья вам хоть как-то поможет
lair
16.01.2024 17:42Много платят и работа интересная у экспертов, а не у архитектора / CTO.
Гм, а архитектор - это не эксперт?
Вот сейчас обидненько как-то.
funca
16.01.2024 17:42Архитектор это профессия. Как и в любой другой сфере деятельности дилетантов здесь тоже хватает. Ну и платят тоже по разному.
lair
16.01.2024 17:42Но архитектор вполне может быть экспертом, так что противопоставление "а не" здесь выглядит неуместным.
ivankudryavtsev
16.01.2024 17:42+1Надо питаться правильно, а не есть только сырые овощи.
Надо стремиться быть экспертом (в своем деле), а не стремиться (к должности) архитектора или тимлида.Противопоставление здесь несет литературный, а не чисто логический прием. Можно ли быть экспертом в архитектуре ПО, но давайте подумаем что должно быть первичным - экспертиза, задающая сутевую составляющую или должностность, задающая назначенную?
lair
16.01.2024 17:42+1Можно ли быть экспертом в архитектуре ПО, но давайте подумаем что должно быть первичным - экспертиза, задающая сутевую составляющую или должностность, задающая назначенную?
Когда я говорю "архитектор", я имею в виду функцию, а не должность. Эта функция подразумевает некие обязанности и компетенции, которых нет у разработчика. Поэтому нельзя быть архитектором, не имея этих компетенций. С какого момента называть компетенции экспертизой - вопрос весьма субъективный.
Надо стремиться быть экспертом (в своем деле), а не стремиться (к должности) архитектора или тимлида.
...а поскольку выше я сказал, что функции разработчика и архитектора отличаются, становится понятно, что в моей системе ценностей, если кто-то разработчик, то быть экспертом в своем деле и стремиться быть архитектором - это разные устремления, потому что они приводят к разному результату (но в конце обоих этих результатов - интересная работа, просто разная). И есть разработчики, которым хочется больше копать в одну сторону, а есть те, кому - в другую (а есть те, кому хочется копать в ту самую третью сторону управления).
Именно поэтому я считаю, что противопоставлять это вредно.
ivankudryavtsev
16.01.2024 17:42Вообще не обязательно. Название не обязано соответствовать наполнению.
HEXFFFFFFFF
16.01.2024 17:42+9Я 35 лет в разработке и читать такие посты мне в общем смешно... Во первых я считаю что все это деление на джуниор, мидл, лид итд это очень условно, выдумка жуликов каких то. Во вторых в IT есть два абсолютно разных типа работ- программировать и руководить программистами. Это абсолютно разные профессии не имеющие между собой почти ни чего общего. Уметь писать код совсем не означает уметь руководить программистами, и наоборот. В третьих- я тут недавно обнаружил- 99% молодых специалистов умеют писать код но не умеют сделать законченный продукт. Когда я начинал задачи выглядили так - сделать сайт, написать программу, разработать устройство, создать сервер, т.е. сделать что то законченное чем может пользоваться юзер. Сейчас программисты умеют делать фронэнд, бэкэнд, писать на питоне, пользоваться гитом, но не умеют сделать продукт. И не понимают что конечная цель их работы это не строчки кода, не процесс, а результат, которым будет пользоваться дядя Вася из соседнего подезда, и который про IT ни чего не знает и знать не должен.
Именно это не понимание программистами конечной цели, не способность понять задачу целиком. Не способность вместе делать продукт, а не писать код, делает их работу низкоквалифицированной и малоплачиваемой. Вот в данной статье я вижу автора увлеченного процессом, а не результатом. Человека который за деревьями не видит леса. Я стараюсь, по возможности, таких в пректы не брать.
Kreastr
16.01.2024 17:42+2Я согласен с выдуманным делением, но не согласен с жуликами. Все это просто вынужденная классификация, которая хоть как-то понятна тем, кто хочет "управлять программистами". При этом самые продвинутые варианты из тех что я видел подходят к этой системе гибче и делят на уровни по отдельным скилам, а не общей компетенции. Правда потом как-то хитро усредняют, чтобы понять какую же зарплату "честно" платить. Так что скорее от дефицита матмоделей такой примитив имеем.
aleko855 Автор
16.01.2024 17:42-4Это две разные профессии, но с тем что они не имеют ничего общего я не согласен. Хороший руководитель тот, кто лучше других умеет делать свою работу.
lair
16.01.2024 17:42+7Хороший руководитель тот, кто лучше других умеет делать свою работу.
Гм. Работа руководителя - руководить. Хороший руководитель - тот, кто хорошо руководит. При этом он может быть не лучшим программистом в команде. Он даже вообще может не быть (практикующим) программистом.
aleko855 Автор
16.01.2024 17:42-3lair
16.01.2024 17:42+6То, что это сказал Джобс, еще не значит, что это обязательно верно.
Я знаю больше одного хорошего разработчика, которые так себе менеджеры. А из двух лучших менеджеров в моей жизни один вообще не разработчик (был, по крайней мере), а второй не был практикующим разработчиком на момент, когда мы работали вместе.
aleko855 Автор
16.01.2024 17:42-2Куда ему до жизненного опыта архитектора из Монреаля
lair
16.01.2024 17:42(переходить на личности - не лучший способ вести дискуссию)
Дело не только в жизненном опыте, дело еще в том, что между 1985 и 2024 годами индустрия поменялась, и у нас теперь есть не только "professional managers from the outside".
aleko855 Автор
16.01.2024 17:42Какие тут личности, я указал вам на то, что вы ставите под сомнения слова человека, который точно знал как руководить компании, противопостовляя это своему личному опыту.
Ну поменялась индустрия, а менеджеры не поменялись и подходы все те же самые, появились только новые методики.
Однако то что говорите выРабота руководителя - руководить
Это в корне неправильная позиция, такой логикой можно предположить что менеджер чупа-чупса может придти и начать управлять программистами.
lair
16.01.2024 17:42+1Какие тут личности
Ровно такие: вы подразумеваете, что мой жизненный опыт имеет меньший вес, чем опыт Джобса, потому что я - архитектор из Монреаля.
вы ставите под сомнения слова человека, который точно знал как руководить компанией
Даже люди, которые точно знают, как руководить компанией, могут ошибаться в вопросах назначения отдельных людей. И да, если слова какого-то человека, не подтвержденные фактами, противоречат наблюдаемому мной опыту, я ставлю их под сомнение, это вообще нормально.
А Джобс, кстати, был great individual contributor? А то вот википедия пишет:
According to Apple co-founder Steve Wozniak, "Steve didn't ever code. He wasn't an engineer and he didn't do any original design...". Daniel Kottke, one of Apple's earliest employees and a college friend of Jobs, stated: "Between Woz and Jobs, Woz was the innovator, the inventor. Steve Jobs was the marketing person." [...] Although Jobs had little involvement in the engineering and technical side of the original Apple computers, Jobs later used his CEO position to directly involve himself with product design.
Выглядит так, что он в лучшем случае занимался дизайном, но не разработкой ПО. Умел ли он делать дизайн лучше всех других людей в компании?
а менеджеры не поменялись и подходы все те же самые, появились только новые методики.
Вы себе противоречите. Если появились новые методики, значит, подходы не те же самые.
Это в корне неправильная позиция, такой логикой можно предположить что менеджер чупа-чупса может придти и начать управлять программистами.
Нет, нельзя. В "уметь руководить" входит понимание предметной области управления.
aleko855 Автор
16.01.2024 17:42Так он и не занимался тех частью никогда
lair
16.01.2024 17:42+1Так он и не занимался тех частью никогда
Тогда как же он может руководить технологической компанией?
Это противоречит вашему же "хороший руководитель тот, кто лучше других умеет делать свою работу."
aleko855 Автор
16.01.2024 17:42Нет, не противоречит.
У него в подчинении были такие же управленцы которых он описывал и речь шла о них.
Раз речь зашла об управлении компании то там своих забот полно, помимо разработки продукта и на все это есть свои методики и опять же, чтобы хорошо руководить компании недостаточно просто «уметь руководить».
В "уметь руководить" входит понимание предметной области управления.
Понимание на каком уровне? Поверхностном? - это плохой руководитель.
Углубленном? - это специалист, о котором я рассказываю
lair
16.01.2024 17:42У него в подчинении были такие же управленцы которых он описывал и речь шла о них.
Как так получается, что менеджер в команде разработки должен быть, по вашему мнению, хорошим разработчиком, а вот его менеджер - уже не должен? Как это работает?
Понимание на каком уровне? Поверхностном? - это плохой руководитель.
На уровне, достаточном для управления. Это, весьма очевидно, не обязательно лучший специалист в команде.
aleko855 Автор
16.01.2024 17:42Да, так и получается, бизнес передает задачи тех команде, а разработчик лид их правильно делегирует на команду, это и называется грамотное руководство.
вы подразумеваете, что мой жизненный опыт имеет меньший вес, чем опыт Джобса
И по поводу этого, я ничего не подразумеваю, вы были первый кто сказал что ваш пример из жизни для вас рабочий, значит его, вероятно нет
lair
16.01.2024 17:42а разработчик лид их правильно делегирует на команду, это и называется грамотное руководство.
И по-вашему, чтобы правильно делегировать задачи в команду, нужно быть лучшим разработчиком в команде? А как определить, в какую команду делегировать, если их несколько?
Я обращаю ваше внимание, кстати, что вы незаметно так подменили "руководитель" на "разработчик-лид", хотя это не обязательно одно и то же (я же не зря постоянно спрашиваю, что вы имеете в виду под "лидом").
И по поводу этого, я ничего не подразумеваю, вы были первый кто сказал что ваш пример из жизни для вас рабочий, значит его, вероятно нет
Нет, я этого не говорил. Я говорил, что то, что он сказал, не обязательно верно, потому что существуют контрпримеры. Это не делает то, что он видел, неверным, это делает неверным обобщение, которое он озвучил, а вы повторили.
aleko855 Автор
16.01.2024 17:42По сути каким бы лидом ты ни был: тимлид, техлид. Везде нужны навыки описанные мной в этой статье, не получится сидеть в углу писать и писать свой код. Для того чтобы придуманную вами систему не испортили, а пользовались ей должным образом, вам надо наложить на нее ограничения, эти ограничения можно называть по разному, но я называю их руководящими процессами.
lair
16.01.2024 17:42По сути каким бы лидом ты ни был: тимлид, техлид.
Но у них же разные функции!
Везде нужны навыки описанные мной в этой статье
Нет, техлиду не обязательно следить за статусом задач, а тимлиду, при наличии техлида (или корпоративной политики) не обязательно следить за ветками и архитектурой и ревьювить PR.
не получится сидеть в углу писать и писать свой код.
Это одна вещь, которую не всегда понимают люди, которые хотят идти в тимлиды из разработчиков - что может вообще не получится писать код. Так надо ли им туда идти?
aleko855 Автор
16.01.2024 17:42Я не говорил что вам надо следить за статусом задач, я говорил что вам надо правильно организовать комфортное для разработчиков пространство на борде и четко следовать определенным инструкциям.
Я так же не говорил что именно вы должны ревьюить PR.
Какую работу должен уметь лучше всех делать ее руководитель?
Это не тот случай где описывается история того как вырасти в руководителя. Очевидным будет ответ, что у них будет PM, который будет давать каждому из них бизнес задачи, а они сами будут выдумывать как их решить.
Здесь нет тех процессов, которые я описываю
lair
16.01.2024 17:42я говорил что вам надо правильно организовать комфортное для разработчиков пространство на борде
Это не задача техлида.
Я так же не говорил что именно вы должны ревьюить PR.
Тогда зачем же руководителю команды быть лучшим разработчиком?
Это не тот случай где описывается история того как вырасти в руководителя. Очевидным будет ответ, что у них будет PM, который будет давать каждому из них бизнес задачи, а они сами будут выдумывать как их решить.
Стоп-стоп-стоп. Кто руководит этой командой? Откуда он взялся?
Здесь нет тех процессов, которые я описываю
Как это нет? Там есть и борда, и ветки, и ревью PR, и многое другое. Это полноценная команда с настроенным процессом разработки.
aleko855 Автор
16.01.2024 17:42Это не задача техлида.
Это не обязательная задача тех лида я бы сказал, опять же, хочешь сделать хорошо, сделай это сам.
Тогда зачем же руководителю команды быть лучшим разработчиком?
Не обязательно надо быть лучшим, одно из главных качеств прекрасно разбираться в том что ты делаешь и желание руководить.
Чтобы иметь понимание как и что делать
Как это нет? Там есть и борда, и ветки, и ревью PR, и многое другое. Это полноценная команда с настроенным процессом разработки.
Это не полноценная команда, это организация из нескольких сотрудников.
Полноценная команда это когда приходит бизнес и говорит: "ребята, вооот такое приложение хочу". А лид команды потом эту идею превращает в явь и делигирует куски реализации своей команде.
В вашем примере одному андроид разработчику ненадо никому ничего делигировать, он работает один над своим приложением, как и остальные работают одни над своими процессами.
lair
16.01.2024 17:42Это не обязательная задача тех лида я бы сказал
Если техлид занимается организацией спринта, он уже не только техлид. Разделение обязанностей не просто так.
опять же, хочешь сделать хорошо, сделай это сам
Тогда зачем команда? Надо все самому делать.
Не обязательно надо быть лучшим
Вы же написали выше: "Хороший руководитель тот, кто лучше других умеет делать свою работу."
одно из главных качеств прекрасно разбираться в том что ты делаешь
А что конкретно обязательно делает руководитель команды, кроме руководства?
и желание руководить.
Вот тут я вам процитирую фразу из того же интервью Джобса, на которое вы ссылались выше, которая идет сразу за фразой про great individual contributors: "who never ever wanted to be a manager". Забавно, как вы удобное вам оставляете, а остальное выкидываете.
Чтобы иметь понимание как и что делать
Чтобы иметь понимание, достаточно понимания. Это совсем не то же самое, как, например, умение что-то сделать самому.
Это не полноценная команда, это организация из нескольких сотрудников.
А откуда вы, извините, берете определение "полноценной команды"?
Полноценная команда это когда приходит бизнес и говорит: "ребята, вооот такое приложение хочу". А лид команды потом эту идею превращает в явь и делигирует куски реализации своей команде.
Прекрасно. Может такая команда это сделать без аналитиков и тестировщиков? ("очевидно, что" нет) Вопрос остается актуальным - какую конкретно активность должен уметь "лучше других" делать руководитель этой команды, чтобы успешно ей руководить?
В вашем примере одному андроид разработчику ненадо никому ничего делигировать, он работает один над своим приложением, как и остальные работают одни над своими процессами.
Им не надо ничего делегировать, но им всем надо работать вместе, чтобы получился результат. В моем понимании это и есть команда.
lair
16.01.2024 17:42Вот тут я вам процитирую фразу из того же интервью Джобса, на которое вы ссылались выше, которая идет сразу за фразой про great individual contributors: "who never ever wanted to be a manager". Забавно, как вы удобное вам оставляете, а остальное выкидываете.
А дальше вставка про человека, которого Джобс назначил руководить производством макинтошей, хотя раньше человек был финансовым контролером. Это как сочетается с предыдущей фразой?
aleko855 Автор
16.01.2024 17:42Если техлид занимается организацией спринта, он уже не только техлид. Разделение обязанностей не просто так.
Все он тех лид, все эти разделения обязанностей абстрактные понятия
Тогда зачем команда? Надо все самому делать
Чтобы команде которой вы руководите было комфортно работать
Вы же написали выше: "Хороший руководитель тот, кто лучше других умеет делать свою работу."
Вы не скопировали мою цитату полностью:
Не обязательно надо быть лучшим, одно из главных качеств прекрасно разбираться в том что ты делаешь
А что конкретно обязательно делает руководитель команды, кроме руководства?
Рассказывает как и что делать
Забавно, как вы удобное вам оставляете, а остальное выкидываете.
Вы меня ни на чем не подловили, я не претендую на роль лучшего руководителя, которого описывает Джобс, как вы сказали, возможно это не истинна, а возможно он и прав.
Чтобы иметь понимание, достаточно понимания. Это совсем не то же самое, как, например, умение что-то сделать самому.
Простое понимания как строить NodeJS приложения не поможет вам управлять отделом разработки NodeJS.
А откуда вы, извините, берете определение "полноценной команды"?
Из личного опыта
Прекрасно. Может такая команда это сделать без аналитиков и тестировщиков? ("очевидно, что" нет)
Ну конечно может, многие программисты владеют навыками тестирования и аналитики в том числе. (Я конечно не обесцениваю эти профессии, но как факт ответ: да)
Им не надо ничего делегировать, но им всем надо работать вместе, чтобы получился результат. В моем понимании это и есть команда.
Если сейчас не впадать в обсуждения определении, то и в моем, наверное это команда. Еще раз, статья о том как помочь тем у кого описанных в статье процессов нет.
lair
16.01.2024 17:42Все он тех лид, все эти разделения обязанностей абстрактные понятия
Тогда в чем разница между техлидом и тимлидом, если это "абстрактные понятия"?
Чтобы команде которой вы руководите было комфортно работать
Нет, зачем мне вообще руководить командой, если я все могу сделать сам лучше?
Вы не скопировали мою цитату полностью
Нет, я скопировал вашу оригинальную цитату полностью.
Там было именно "лучше других".
Рассказывает как и что делать
Каждому участнику команды?
как вы сказали, возможно это не истинна, а возможно он и прав.
Ну вы уж определитесь: либо он прав, и тогда ваше предположение ошибочно, либо он не прав, и тогда мы про него забываем и начинаем думать самостоятельно.
Простое понимания как строить NodeJS приложения не поможет вам управлять отделом разработки NodeJS.
Поможет. Почему нет?
(отделом разработки NodeJS или на NodeJS?)
Ну конечно может, многие программисты владеют навыками тестирования и аналитики в том числе.
"Владеют навыками" не означает "хорошо делают". Поэтому нет, не может. По крайней мере, может далеко не всякий продукт.
Так что вопрос, что должен уметь делать руководитель, остается актуальным.
Если сейчас не впадать в обсуждения определении, то и в моем, наверное это команда.
Вы выше написали, что это не команда. Как так?
Еще раз, статья о том как помочь тем у кого описанных в статье процессов нет.
Нет, статья о том, как начать управлять. Это не одно и то же.
(Ответ-то очевиден: надо научиться управлять и начать это делать, к этому вопросов нет. Вопрос в основном в том, кому и зачем это стоит делать.)
aleko855 Автор
16.01.2024 17:42-1Нет, зачем мне вообще руководить командой, если я все могу сделать сам лучше?
Это уже называется абсолютное нежелание понять, о чем вам говорят
Нет, я скопировал вашу оригинальную цитату полностью.
Я оставил мою оригинальную цитату в предыдущем комменте
Каждому участнику команды?
В целом да, в этом и смысл руководить
Ну вы уж определитесь: либо он прав, и тогда ваше предположение ошибочно, либо он не прав, и тогда мы про него забываем и начинаем думать самостоятельно.
Все что я хотел сказать о цитировании Джобса, я сказал в предыдущем комменте
Поможет. Почему нет?
Потому что вы понятия не имеете как строится NodeJS приложение в реальной работе. Если у вас простое понимание как строятся NodeJS приложения, то скорее всего все что вы знаете это: что такое сервисы, контроллеры, бд и что все на JS.
"Владеют навыками" не означает "хорошо делают". Поэтому нет, не может. По крайней мере, может далеко не всякий продукт.
Ох, давайте еще углубимся в детали. Хорошо или не очень хорошо, задачу они выполнят. Ровно так же хорошо или плохо с этой задачей может справится профессиональный тестировщик.
Ответ-то очевиден: надо научиться управлять и начать это делать, к этому вопросов нет
Ого, я тут целую статью пишу, а вы все в одном предложении описали, потрясающе
lair
16.01.2024 17:42Я оставил мою оригинальную цитату в предыдущем комменте
Гм. Нет:
Хороший руководитель тот, кто лучше других умеет делать свою работу.
(https://habr.com/ru/articles/786886/#comment_26388010)
Потому что вы понятия не имеете как строится NodeJS приложение в реальной работе.
Если у меня нет понимания, как строится приложение NodeJS в реальной работе, у меня нет понимания как строить NodeJS приложения. А вы сказали, что оно есть.
Хорошо или не очень хорошо, задачу они выполнят.
Извините, что? Вам не важно качество выполнения?
Тогда нам действительно нечего обсуждать.
aleko855 Автор
16.01.2024 17:42Извините, что? Вам не важно качество выполнения?
Может вы тогда и на эту полную мою цитату ссылку оставите. Вы еще после такого говорите о том что я только удобный контекст цитирую?)
Тогда нам действительно нечего обсуждать.
Ваш первый комментарии был по поводу роли архитектора в этой статье, а потом вы сказали что вам в принципе не нужны знания руководителя. Нам с вами было нечего обсуждать с самого начала, я в целом не понимаю, почему вы с вашими убеждениями вторые сутки комментируете эту статью.
lair
16.01.2024 17:42Может вы тогда и на эту полную мою цитату ссылку оставите.
Конечно, вот цитата:
Хорошо или не очень хорошо
Я это читаю как "мне не важно, насколько хорошо разработчик протестирует код, и какие на входе будут требования". Потому разработчики могут тестировать не "не очень хорошо", а плохо, а требования писать (а уж особенно собирать) еще хуже.
я в целом не понимаю, почему вы с вашими убеждениями вторые сутки комментируете эту статью.
Потому что я не хочу, чтобы у других людей, которые пришли сюда ее прочитать, было ощущение, что то, что вы говорите про управляющую роль - верно.
aleko855 Автор
16.01.2024 17:42-1Я вам помогу процитировать её
Хорошо или не очень хорошо, задачу они выполнят. Ровно так же хорошо или плохо с этой задачей может справится профессиональный тестировщик.
Потому что я не хочу, чтобы у других людей, которые пришли сюда ее прочитать, было ощущение, что то, что вы говорите про управляющую роль - верно.
Вам то откуда знать верно это или нет, вы сами сказали что для архитектора не нужны навыки руководителя, вы архитектор => у вас этих навыков быть не должно
lair
16.01.2024 17:42Хорошо или не очень хорошо, задачу они выполнят. Ровно так же хорошо или плохо с этой задачей может справится профессиональный тестировщик.
Нет, не "ровно так же хорошо". Професииональный тестировщик, при прочих равных, сделает эту задачу лучше.
Вам то откуда знать верно это или нет
Оттуда, что я достаточно долгое время работал тимлидом или руководителем отдела разработки.
вы сами сказали что для архитектора не нужны навыки руководителя, вы архитектор => у вас этих навыков быть не должно
То, что они мне не нужны, не значит, что у меня их нет.
aleko855 Автор
16.01.2024 17:42Вы выросли в архитекторы из тимлида и при этом доказывали мне что это невозможно? Загадочный вы человек и очень непостоянный.
lair
16.01.2024 17:42+1Вы выросли в архитекторы из тимлида
Нет, я вырос в архитекторы из разработчика. А тимлидство получил уже как архитектор.
и при этом доказывали мне что это невозможно?
Я не доказывал, что это невозможно. Я говорил, что тимлид на этом пути не обязателен.
funca
16.01.2024 17:42+2А что конкретно обязательно делает руководитель команды, кроме руководства?
Рассказывает как и что делать
Задача руководителя выбирать людей и указывать им цели - пресловутые who/what/when, - контролируя потом риски и результаты. А how "как" это работа специалистов - для этого их и нанимают.
Если специалисту приходится рассказывать как делать свою работу, то здесь от руководителя требуется во время определить риск. А дальше нужен просто более опытный специалист: учитель, тренер, наставник, - а не руководитель.
Они, разумеется, тоже будут ставить цели и контролировать результаты - в своих образовательных активностях. Но это занятие немного другого рода.
funca
16.01.2024 17:42+1Ну вот руководитель со знаниями специалиста, или специалист с организаторскими способностями это комбо, на самом деле не так часто встречающееся в природе. Если вы нашли такого человека, то считайте, что выиграли в лотерею. Они не будут тупить, при виде слов фронтенд-бекенд, или ждать аналитиков, чтобы зафиксировать ключевые решения после встречи. Мне кажется слова Джобса об чём-то таком.
Опять же, рассчитывать на выигрыш в лотерее это так себе стратегия. Поэтому я согласен и с @lair - нужно уметь работать с тем, что имеем.
aleko855 Автор
16.01.2024 17:42Так никто про лотерею и не говорил, основной посыл такой:
Если ты хочешь стать в руководящей должности программистом, то вот тебе советы как развить в себе эти черты.
funca
16.01.2024 17:42Да мысли в вашей статье классные. Попытаться описать себя в роли руководителя это хороший способ понять о чём это вообще. Даже оставаясь на ролях специалиста, потом начнёшь больше ценить такую работу. Сложно? Трудно? А то.
lair
16.01.2024 17:42Или вот тоже интересный вопрос: есть команда, состоящая из трех разработчиков, одного аналитика и двух тестировщиков. Какую работу должен уметь лучше всех делать ее руководитель? А если из этих трех разработчиков один занимается фронтом, один - бэком, а один - мобилой?
stitrace
16.01.2024 17:42+2Это не жулики, а просто люди, людям свойственно по природе заниматься классификацией. Эта же проблема во многих областях человеческих знаний, как яркий пример в фундаментальных разделах биологии, которые занимаются классификацией видов живых существ. Всем понятно, что эволюция это беспрерывный и плавный процесс, но все равно классифицируют по видам. В результате получаются всякие коллизии постоянно в виде «подвидов» и постоянные споры.
alexhott
16.01.2024 17:42+2джуниор, мидл, лид итд это очень условно, выдумка жуликов каких то
это называется нематериальная стимуляция
в других местах инженер 1,2 категории, ведущий старший - хоть как назови но принцип тот же.
И это реально работает, но это как раз вопрос руководителя который может не иметь отношения к разработке, а "хорошо управлять"
alexhott
16.01.2024 17:42+2Объять необъятное.
Если вы работаете на одном предприятии около 300 чел и предприятие не разработчик ПО, а чисто для себя продуктовая разработка - то вперед все описанное в одного внутри своей конторы - и в руководители ИТ. Там еще и бюджет и годовые отчеты и закупки и куча всего не ИТ для общего развития.
Если хотите в ИТ развиваться то выбирайте направление. аналитика, разработка, архитектура и т.д. и специализируйтесь в нем. Покрыть все качественно невозможно.
А управление людьми - это уже отдельная тема, тут как раз можно поверхностно во все включиться чтобы людей в команде понимать и на одном языке разговаривать, но как спец в ИТ уже развиваться не получиться.
esselesse
16.01.2024 17:42А для чего это все?
Если это пытаться внедрять на проекте, на котором все прекрасно работает и без этого - такие потуги в сторону излишней структуризации выйдут боком.
Из разряда созвонов для организации созвонов.
lair
Гм. Почему вы думаете, что управляющий лид - это обязательный шаг на пути к архитектору? Это же независимые направления развития.
И снова - почему вы смешиваете технические компетенции с организационными?
aleko855 Автор
Ну, отвечая на первый вопрос, лид может быть ступенью к развития в архитекторы, а в целом я не обозначал что это обязательный шаг.
Во втором же случай, я говорю лишь о том, что у начинающего разработчика нет понимание ни в одной из этих сфер
lair
Управляющий? Нет, это шаг, который к архитектуре отношения не имеет, и никак не приближает.
Проблема в том, что у вас в статье указан "лид", но даже не сказано, что вы имеете в виду под этим.
Но нужно ли начинающему разработчику понимание того, как управлять людьми, если он не собирается управлять людьми?
aleko855 Автор
Я понятия не имею откуда у вас такая уверенность в этом, у меня есть личные примеры когда из лида человек выростал в архитектора, хоть эти и понятия не связаны, собственно статья вообще не об этом.
Эта статья как раз написана для тех людей, которые собираются управлять. Прочитайте пожалуйста заголовок.
lair
В чем? В том, что работа тимлидом может не давать никаких навыков архитектора? Из наблюдений за тимлидами.
Это не означает, что работа лидом этому человеку как-то для этого помогла.
Ну и еще раз повторю: вы даже не уточняете, о каком конкретно "лиде" идет речь.
Тогда уберите из нее упоминание архитектора и технические компетенции.
Если человек хочет расти в архитектора, ему не обязательно учиться управлять.
aleko855 Автор
Любой продукт можно написать и отдать, так чтобы пользователь сам в нем разбирался, другой вопрос в том, разберется ли он в нем.
Обязанность архитектора настроить техническую составляющую проекта и в этой статье есть все для того чтобы объяснить почему те или иные решения были выбраны, почему программист должен использовать все так, а не иначе, как помочь ему в понимании системы, без этого понимания, какой бы технически грамотный архитектор ни был, его система не будет работать так, как он запланировал.
lair
Какое отношение это имеет к дискуссии?
Во-первых, нет, в ней нет "всего для того, чтобы объяснить". Я бы даже сказал, в ней нет практически ничего об этом (про документирование архитектуры написано много интересного, в том числе и на хабре).
Во-вторых, ваша статья, по вашему же утверждению, для людей, которые собираются управлять. Чтобы стать архитектором, не нужно учиться управлять. Значит, чтобы стать архитектором, вашу статью читать не надо.
aleko855 Автор
Ну хорошо, не читайте, вы вытащили из статьи одно слово и построили на этом целую ветку обсуждении. Эта статья не об архитекторах и не о документации.
funca
Ну если вы хотите, чтобы ваши архитектурные решения воплощались в жизнь в том виде, в котором вы это задумали, да и вообще воплощались где-нибудь, то без навыков организовывать и управлять людьми здесь никуда. Людям свойственно делать так, как им удобнее - трения и отклонения норовят возникнуть как со стороны разработки, так и бизнеса. А если вы работаете не в одиночку, а у вас там целая команда, то - тем более.
aleko855 Автор
Это один из немногих непредвзятых комментариев здесь, браво
lair
Совершенно не обязательно. Для этого есть другие люди, которые и занимаются управлением.
Грубо говоря, если ко мне как к архитектору пришли и попросили дизайн для вот такой-то функциональности, то моя задача - сделать такой дизайн, а организовывать процесс его внедрения буду не я.
Если я работаю не в одиночку, а в составе целой команды, то у это команды есть руководитель (тру стори!). Он ей и управляет, а совсем не я.
funca
Ну а кто будет организовать процесс сбора требований, проводить встречи со стейк холдерами, пушить экспертов, верифицировать и оценивать решение с командами? Без организаторских навыков, имхо, тут будет тяжело. Может на начальных этапах карьеры за вас этим будут заниматься более опытные ребята. Но сидеть так вечно в джунах это какой-то инфантилизм.
lair
Аналитик.
Руководитель проекта.
Архитектор и тимлиды.
Без организаторских навыков тяжело, если заниматься организацией. Но можно просто не заниматься организацией.
В моем опыте несколько наоборот: на начальных этапах карьеры более опытные люди всеми силами пытаются это на тебя свалить, а когда сам вырастаешь до достаточного уровня, можно просто сказать "мое время слишком дорого, чтобы я его тратил на организацию встреч".
funca
Сказать кому? Выглядит скорее как навык пушбэчить, нежели делегировать. Это срабатывает когда ответственность лежит на ком-то другом. Ну то есть собрать контакты, подготовить материалы и презу, написать агенду, а потом mfu с экшен айтемами по результатам это не дорого. А жамкнуть пару кнопок в календаре аутлука - тут без проджекта с аналитиком уже ни как?
lair
Тому, кто этого требует.
Это дорого, но этим тоже можно максимально не заниматься.
Организация встречи - это не "жамкнуть пару кнопок в календаре", а все, что вы сказали выше, кроме подборки материалов и подготовки презентации.
tommyangelo27
В моей прошлой фирме на некоторых проектах была даже отдельная роль Project Coordinator, который снимал обязанность организации встреч с PMа. Также он "дёргал" напоминаниями и следил за заполнением некоторых форм.