Есть в Айти стандартные грейды: Джун, Мидл, Синьор.
Руководителей ИТ проектов тоже можно разложить по этим уровням. Мне это помогает четче формулировать требования к сотруднику и куда ему дальше расти. Вам может помочь понять, что надо подтянуть, чтобы достичь нужного уровня, какие есть перспективы дальше. А если вы ищете РП – можете использовать для описания работы в вакансии ?
Непричеметр (он же дисклеймер): эта статья – мое личное мнение, основанное на большом числе собеседований, которые я провел и прошел (суммарно больше 400). У меня нет статистических данных, я не проводил опросы и так далее. Зато почти каждый год на протяжении 20 лет я ходил по собеседованиям, последние 15 лет я собеседовал РП, а последние три года я непрерывно искал аналитиков и менеджеров, так что сформулировал четкие критерии отбора, которыми и хочу поделиться в статье ниже.
Итак: как стать джуном, как расти дальше до синьора и кем быть потом?
Если вы смотрите варианты, как начать работать РП в IT – эта часть для вас. Вам будет намного проще, если у вас уже есть опыт выполнения проектов вне ИТ, опыт руководства и мотивации команды. Тут у нас то же самое, только мы пасем котов (это из классической книги про то, как управлять программистами, которым на вас пофигу). Если вы уже управляли – проблематика таже самая: всем все надо быстрее, выше и сильнее, работники не работают, поставщики опять все продолбали и тп. Вам понадобится только изучить новые процессы (процесс управления проектом и процессы разработки ПО) и документацию.
Если у вас нет управленческого опыта, а вы хотите быть РП – будет сложнее.
Джун:
знает и может объяснить, что такое ТЗ**. Сам писал какие-то функциональные требования, юзкейсы и согласовывал их с заказчиком;
видел заказчика в лицо. Хоть какого-то. Есть хотя бы небольшой опыт переговоров (это когда ваша позиция отличается от позиции другого человека и надо как-то договариваться, а не просто на все согласиться);
знает, что такое проектный план;
знает, для чего нужны тестировщики и на основании чего они работают (но может не знать, что такое ПМИ);
есть базовое понимание того, что работа должна делаться в срок***;
есть опыт сдачи проекта заказчику (тут неважно, в какой области, важно, что вообще есть опыт «что-то зафиксировать и сделать командой в срок»);
умение ставить задачу разработчику хотя бы на пальцах («ну, там, вот это - туда, потом там это, и чтобы «уух!»).
Джун курильщика:
не понимает, что такое функциональные требования. Это значит, что он не сможет их сформулировать сам и не сможет проверить за аналитиком. Этому РП нужен нянька начальник + аналитик + хороший разработчик, чтобы учить. Его обучение может влететь в копеечку.
не имеет опыта сдачи проектов заказчику вообще (а значит и близко не сталкивался с проблемами при сдаче). Взяв такого,первые два года вы точно будете страдать от срыва сроков, а дальше – как повезет.
«если я не успел в срок, я попрошу заказчика перенести срок немного. А лучше сроков вообще не обещать»
Миддл:
понимает жизненный цикл проекта на уровне: «какой-то пресейл», «анализ», «разработка», «сдача-приемка» - не менее.
понимает документацию проекта на каждом из этих шагов (устав, план, контракт, ТЗ, детальный дизайн, ПМИ**). Понимает = умеет рассказать, что обязательно в этих доках должно быть;
понимает, на основании чего работает его проект (Устав или контракт, или просто – пацаны договорились и где-то зафиксировали).
имеет опыт ведения реальных проектов от 2х лет. Это значит – не бумажки перекладывал или был администратором, а реально делал и сдавал ИТ проекты. Это легко проверяется на собеседовании: если человек не может внятно рассказать, что именно он делал хотя бы 2 года – он врет про свой опыт.
имеет опыт решения проблем и базовое понимание механизма эскалации на проекте (команда-рп-заказчик внешний-внутренний-спонсоры)***;
имеет опыт факапов и не боится им делиться
имеет реальный опыт сдачи своих проектов в срок и в бюджет.
Миддл курильщика:
плывет на вопросах: «какие основные разделы обязательно должны быть в ТЗ?» или «для чего и как пишется ПМИ?»
не знает жизненного цикла проекта, описанного выше: это означает, проекты делал, но маленькие, пока еще джун;
на вопрос «расскажите про парочку факапов из работы?» отвечает, что их не было (не умеет признавать свои косяки или просто их реально не было. Оба варианта плохие).
в тестовой задачке легко смещает сроки проекта вправп
«ой, а что такое декомпозиция в трекере?»
Синьор:
сам вам расскажет, как надо. Может взять ваши шаблоны, а может сделать по своим;
отлично знает жизненный цикл проекта от появления идеи до сдачи в эксплуатацию и всех доков которые там надо делать;
доставал проекты из кризиса и с удовольствием рассказывает про это;
зафакапил парочку, сделал выводы и тоже может про это рассказать;
умеет в пресейл. Умение делать красивые презентации – плюс, но необязательно
может объяснить на пальцах, чем отличаются страшные слова: PMBoK, Agile, SCRUM. более того, понимает что и когда надо применять;
умеет в мотивацию, может рассказать парочку примеров «из жизни»;
расскажет вам про один два по-настоящему больших проекта уровня внедрения Федеральной ГИС или что-то подобное;
умеет организовать цикл разработки для команды 20+ разработчиков (реальных, а не мифических).
Синьор курильщика:
«я не понимаю, почему мы опять не успеваем»
«зачем я буду вести риски и что это?»
Когда Синьор перерастает позицию РП? Почти всегда это происходит само собой:
вам становится мало одного проекта, вы берете несколько. И вот – у вам портфель проектов, и вы – Руководитель портфеля.
Вам становится скучно с вашим проектом, вы ходите к вашему заказчику и предлагаете поделать что-то еще. Это – бизнес девелопмент.
Вы отлично разобрались в том, что внедряете, и уже сами знаете процессы вашего заказчика лучше него самого. Теперь вы сами формируете дорожную карту на год, а заказчик только радостно хлопает в ладоши. Вы – владелец продукта.
Вы так хорошо делали ваш проект, что заказчик запустил еще несколько и отдал их вам. Но ваших рук не хватает и вам в помощь выдали еще 1-2 подрастающих РП. Вы – руководитель направления ?
Если почему-то так не происходит, значит вы или не Синьор или стоит задуматься, чтобы сменить место работы.
Ну и последнее, на добавку. Про зарплаты на момент августа 2024 года:
джун: 180-230
миддл: 230-350
синьор: 350-500
(по моим собственным данным на основании собеседований за последние полгода, офферов, которые делал я, и которые получали мои менеджеры).
На этом все. Напомню еще раз - это исключительно мой опыт. Если вам есть что добавить - буду рад комментариям, интересно, насколько мой опыт бьется с опытом рынка.
Удачи, и не будьте менеджерами курильщика, будьте хорошими РП!
Сноски
** - : неважно как называется документ, важен принцип: ТЗ или functional requirements, ПМИ или migration strategy, ПЗ к ТП или Detailed design – если человек работал с чем то одним и понимает, зачем оно, он быстро переучится.
*** - как проверить такой опыт на интервью – это отдельный разговор. На уровне РП кандидаты уже давно научились преувеличивать и приукрашивать свой опыт, но правильные вопросы могут показать, кандидат знает, о чем говорит или нафантазировал. Как задавать правильные вопросы, я напишу как-нибудь отдельно.
Комментарии (37)
tentecool
22.08.2024 06:25+1джун: 180-230
миддл: 230-350
то есть между человеком, умеющим делать минимум под присмотром, и средней крепости спецом разница по зп в 50к (а может и вовсе не быть?)
peterzh Автор
22.08.2024 06:25+1да. все зависит от дерзости, умения запудрить мозги на собеседовании и опыта интервьюера. не то, чтобы я настаиваю, мой опыт - такой.
BeLord
22.08.2024 06:25+3Интересно рынок поменялся, раньше требования к мидлу были такие, как тут к сеньору, а без навыков пресайла и с джуном разговаривали со скрипом.
Жизненный цикл проекта далеко не всегда заканчивается сдачей в эксплуатацию, в части проектов жизненный цикл заканчивается, когда систему выводят из эксплуатации, а это значит, что РП должен уметь работать со сроками в 10-15 лет.
Очень вскользь увидел экономику, а в реальных проектах экономика может занимать половину функционала, хотя бы потому, что время и риски всегда связаны с деньгами.
Не увидел делегирования, РП может делегировать организацию работы разработчиков тимлиду и это тоже рабочая схема.
Старт рассуждений начинается с ТЗ, хотя создание ТЗ это этап после предпроектного обследования, качество исполнения которого, как раз впрямую влияет на ТЗ. Я уж молчу, что половина компаний не понимает разницу между ТЗ и ЧТЗ.
ПМИ - вторичный вопрос, на мой взгляд, интереснее спросить про этапы и типы испытаний, про регламент испытаний и взаимодействие с Заказчиком, потому, что эти вопросы показывают базовый юридический бэкграунд РП, без которого количество граблей в проекте кратно растет.
peterzh Автор
22.08.2024 06:25+1классные замечания, спасибо. по пунктам
Да, я сам в шоке. На РП и аналитиков прямо сейчас нереальный спрос, я такого не видел никогда. Все ваши замечания для меня - уже синьор :) но тут надо понимать, что я говорю о проектах 20-50 человек. Но 100. Если смотреть на проекты 100+ человек, то там уровень будет другой, разумеется. Но я таких проектов в РФ знаю мало. Может быть выборка хромает, конечно
Хм. Для меня у проекта есть четкие сроки. В госухе всегда есть развитие и эксплуатация. Есть капекс и опекс. Проект заканчивается там, где заканчивается капекс. И обычно это три года (что я знаю, проекты уровня создания ФГИС). Впрочем, Госуслуги уже 15 лет развиваются, так то. Тут надо почитать теорию, я не помню определения.
Экономику ИТ проекта, если он не слишком большой, считать достаточно просто: есть оценка, есть план, есть запасы. Этому я и сам могу научить. Но обычно РП знают это, все таки :)
Может. это в синьоре есть: "может организовать работу 20+ человек" - без делегирования лидам он этого как раз сделать не сможет. Вопрос на собеседовании "расскажите о процессе разработки команды 20 разработчиков и инструментах, где вы его автоматизируете"
Согласен. Тут к вашему первому замечанию. Наверное, уровень упал. Часто РП бывают без опыта предпроектного обследования, оно же пресейл. Но делать "по ТЗ" в целом могут.
Вы знаете, отличия предварительных и приемочных испытаний я сам использовал пару раз, когда надо было сдавать строго по ГОСТ, да и система была сложной. Тут вопрос масштаба. Для меня уже это, скорее, синьор
kalinin_krd
22.08.2024 06:25Вы правы, проект имеет сроки начала и окончания. Дальше, как правило, проект переходит в продукт, но не остаётся проектом и управляется Продактами
Zelebublik
22.08.2024 06:25Чего уж вы мелочитесь, напишите уже, что синёр получает от 350 до секстиллион_до_неба.
Откуда срез - хз, снова графоманские приколы хабра)
Пойди займись делом
(я, если кто спрашивал, head of PMO, буквально месяц как закрыл 2 вакансии РП - больше сотни резюме перелопатил).peterzh Автор
22.08.2024 06:25+4не надо грубить
я и сам head of pmo уже много лет и перелопатил больше 100.
расскажите кого и на сколько вы взяли. Очень интересно не меряться размерами должности, а сравнить реальный опыт. Хабр для этого и создавался, вообще то.
DaZdraNaGon
22.08.2024 06:25Вы нанимаете джунов за 180к? Очень интересная информация.
Я порядка 3.5 лет работал руководителем не в ИТ, в прошлом году стал искать первую ИТ работу в проектном менеджменте. Долго искал, очень много отказов, отказы на позиции помощник координатора младшего ПМа за 10к рублей. Вместо этого куча бесплатных стажировок и пет-проектов, обучений самостоятельных, у менторов, на курсах, чтобы потом чудом по знакомству устроиться на 300€ в месяц.
Я тоже не собирал статистику, но возможно реальность всё-таки ближе к моему опыту, судя по сотням и тысячам откликов на вакансии за 50-70к.
peterzh Автор
22.08.2024 06:25Возможно. Одна из целей статьи - это обменяться опытом. Сам я отбором не занимаюсь, последние несколько лет это делают HR. За ними есть грешок: они могут поднимать зарплаты кандидатов, потому что получают % от зарплаты кандидата в итоге. Так что завышение может быть.
Но я также вижу, когда хорошие кандидаты уходят, не приняв наш оффер. Так что вопрос дискуссионный.По вашему кейсу скажу следующее: мне в линкед ине писали несколько кандидатов, мы как то даже собеседовали СЕО закрывшегося ИТ интегратора на позицию РП. Я не взял никого. Причины разные: или человек вообще не владеет предметом (как в статье про джуна - этого нет), обещая, что научится (но у меня нет столько денег и времени), или психологические особенности кандидатов.
Если хотите - киньте мне ваше CV в ТГ (в профиле), я погляжу и скажу свое мнение.
lncln
22.08.2024 06:25Про зарплаты на момент августа 2024 года:джун: 180-230миддл: 230-350синьор: 350-500А вы уверены? Максимальный оффер на миддла, что получала, был 150 до налогов.
peterzh Автор
22.08.2024 06:25+1вы знаете, я последние полгода ищу менеджеров. HR подгоняют таких. И несколько человек отказались от наших офферов в пользу других.
Мои менеджеры получают офферы со стороны на схожие суммы. Я сам пару раз выходил на рынок, чтобы прикинуть свою цену. Мои выводы такие.
Дальше - вопрос личной выборки, умения сделать резюме и себя продать (грубо говоря, не соглашаться на первый оффер, а походить пару мес по рынку и поглядеть).
Я в начале статьи написал, что это личный вывод. Но я реально очень много искал в последнее время и вижу странности на рынке РП. И если у вас есть качества джуна из статьи выше, я готов поспорить, что вы найдете работу в этой вилке. Если не ищется - чтото не так делаете.
Мне самому очень интересно, что на рынке, так что можете в личку мне написать, я погляжу.
tsedilkin
22.08.2024 06:25Поддержу ваш комментарий, цифры кажутся какими-то космическими. Либо нужно очень хорошо найти компанию, которая будет готова такие деньги платить (немного кэп), но лично я таких не встречал за ~10 работы ПМ в ИТ компаниях, дошел через боль до уровня лида, только что-то даже не за 300к, по этому кажется что данные не верны.
peterzh Автор
22.08.2024 06:25+1не спора ради, я просто поделился тем, что я вижу на рынке. Если у вас другой опыт - буду рад если поделитесь. Но не за 10 лет, а последний год-полтора. Потому что сейчас на рынке бум.
Я в 2019 году искал работу и не могу найти. Сейчас за нормальными РП очередь.
Моего ведущего РП (по факту он классный миддл конечно) уже год закидывают офферами от 300 тыс. Если вам интересно - напишите в личку, мне интересно, что у вас. Я смотрю на рынок, мне интересно, что происходит и статья - попытка это понять.
CAMOPKAH
22.08.2024 06:25Дорогой автор, тема действительно интересная. Я понимаю, что многое зависит от конкретных проектов и сферы их применения.
После прочтения у меня возникли некоторые вопросы, и было бы замечательно, если бы вы смогли на них ответить:
1. Что побудило вас написать эту статью?
2. Какую «боль» решает эта статья?
3. Какой ваш проект вызывает у вас наибольшую гордость и почему?
4. В какой основной сфере применяются ваши проекты?
5. Сколько сотрудников может контролировать руководитель портфеля проектов и каких?
peterzh Автор
22.08.2024 06:25+1Здравствуйте. Цель статьи: разобрать отличия джунов миддлов и синьоров, чтобы начинающие и не очень РП могли поглядеть, чего им не хватает, чтобы расти дальше.
Статья основана на большом числе реальных примеров из опыта меня , как РП и меня, как руководителя направлений, ПМО и прочих отделов.
По вашим остальным вопросам я с удовольствием вам отвечу, если вы сразу озвучите их цель. Иначе напоминает собеседование в тональности пассивной агрессии. Я и сам так умею, но, считаю, Хабр не для этого, а для обмена опытом.
Если вы - руководитель, и видите тут лажу, просто напишите. Без проблем, обсудим :)
Dixtox
22.08.2024 06:25Цель проста - поставить вас на место соискателя и посмотреть как вы завалитесь по своим же критериям. Имхо - статья бред и чушь, никакой полезной нагрузки не несёт. Нахватались терминов и трясёте ими как бубенцами, вот только зачем?
Midnight_la
22.08.2024 06:25Давай конструктивнее, получается что критикуешь, но ничего не предлагаешь. Это очень низкий уровень зрелости.
peterzh Автор
22.08.2024 06:25+2спасибо, я понял.
Я по всем темам, написанным мной в статье могу написать по статье. И напишу, для этого и начал писать. Я уверен, что на Хабре есть люди и опытнее и умнее меня. Я с радостью послушаю их опыт и научусь новому.
Для конструктивного обсуждения или спора , как угодно, нужна фактура. Ваше мнение я понял, фактуру дадите? У вас другие критерии отбора? Расскажите.
Критикуя - предлагай, как верно заметили уже
SelkupRus
22.08.2024 06:25+1Благодарю вас за статью! Теперь понятно в какую сторону двигаться.
Вопрос: все навыки и знания, перечисленные в статье, получаются потом, кровью и неудачами в процессе работы или существует хотя бы базовая литература? Имею ввиду кризис-менеджмент, определение сроков, планирование и тд.
peterzh Автор
22.08.2024 06:25+1спасибо. по поводу книг - нет, я ничего этого в книгах не видел, увы. Да и ни разу у меня не получалось софтскиллам научиться по книжкам или лекциям. На словах все просто, а попадаешь в реал - и коленки дрожат :)
Бизнес игры - точно тема, была пара игр, где я почувствовал прямо, что чтото делаю не так. Но хороших тренеров трудно найти. Пока что все на опыте ) может быть я смогу запилить курс, где все это будет, но надо думать :)
leitenant2013
22.08.2024 06:25вам становится мало одного проекта, вы берете несколько - я такое видел только если по факту тащит проект кто-то другой. Не верю короче
peterzh Автор
22.08.2024 06:25зависит от размера проекта и сложности коммуникаций на проекте.
Можно посчитать в условных вебсайта: джун РП делает 1 проект по созданию веб сайта и занят фулл тайм на 3 мес. Миддл может делать их 3 и не продолбать ничего. Синьор сделает 5 (собственно, я как то делал 5). Синьор+ сделает 5 и по пути подружится с заказчиками , поймет, что у них болит и предложит что можно сделать, чтобы решить их боли - то есть биздев
aimfirst
22.08.2024 06:25+1Согласен с автором в отношении уровня зарплат РП. Единственное, конкретизирую свое виденье главного отличительного признака РП - это человек, который лично отвечает за итоговый результат работы других сотрудников. Некоторые уверены, что РП - это человек который может талантливо делегировать свою ответственность (не работу, а именно ответственность). Это не РП - это рафинированный менеджер. Иногда, такая должность звучит как <администратор проекта>. Зарплата таких "РП" действительно может стартовать с гораздо меньших уровней.
leitenant2013
22.08.2024 06:25Вот-вот и поэтому ни о каких нескольких проектах речи не может идти, это уже обычное делегирование и он в лучшем случае будет задавать главный вопрос, ну как дела?
aimfirst
22.08.2024 06:25+1Опять, же дело в контексте. Что называть проектом? У меня основная система над которой трудится проектная команда как бы одна. Но в ней 14 подсистем которые решают разные задачи (на каждой из них раньше специализировалась своя группа разработчиков). По этой системе одновременно может быть в работе 3-4 договора разного размера и срочности: на базовое сопровождение (решение возникающих инцидентов и консультации), на расширенное сопровождение (небольшие доработки по заявкам), на развитие (серьезная модификация подсистем, переход на новые технологии, создание новых подсистем). Это один проект или программа или портфель проектов? Кроме того в проектной команде у нас есть пара внутренних проектов заточенных на создание перспективных продуктов (решение важных, но несрочных задач - по матрице Д.Эйзенхаура). Один из таких проектов описан на Хабре. На эти проекты я стараюсь ежедневно планировать не менее 30% рабочего времени штатных сотрудников. На этих внутренних проектах решаются проблемы превентивного освоения и апробации перспективных технологий, а так же выравнивания неравномерности нагрузки сотрудников (ликвидация mura). Эти же проекты служат "песочницей" для апробации стажеров. Эти же проекты служат буфером (по Э.Голдрату), в случае необходимости решения более срочных задач по заключенным контрактам.
При всем при этом моя должность звучит как <РП> (в прямом подчинении 12 сотрудников, для решения отдельных задач возможно привлечение внешних экспертов). Было бы интересно узнать, как должна звучать моя должность, с точки зрения читателей этой статьи... ;)peterzh Автор
22.08.2024 06:25Тут вопрос, кто отвечает за общий бюджет? Если маржа по всей истории ваша и за ФОт и мотивацию команды отвечаете вы - попахивает руководителем направления.
Если ФОТ не ваш, но у вас есть несколько РП - Директор.
Если РП в подчинении нет, то надо поглядеть, как вы лидами обходитесь. 12 лидов в целом на грани, на мой взгляд :) Мне 7-8 хватало и я просил еще РП
aimfirst
22.08.2024 06:25Маржу я бы, конечно, взял... Да кто ж ее даст... ФОТ и состав команды обосновываю я, исходя из бюджетов договоров (кстати, которые тоже я обосновываю) и текущей ситуации на рынке труда, но окончательное решение принимает вышестоящее начальство. И я не прошу дополнительных РП у начальства, я выращиваю их самостоятельно. Что касается управления, у меня в команде выстроен определенный порядок достижения целей. Любое входящее требование (не только от представителей заказчика, но в том числе и требования вышестоящего руководства и мои требования тоже) регистрируется, на него назначается ответственный, как правило, из числа аналитиков (на текущий момент в группе три аналитика). Ответственный выступает как РП в рамках этого требования (или группы связанных требований). Он отвечает за организацию работ и сдачу результата решения заказчику. Я сам, как правило, осуществляю утверждение и контроль исполнения сроков и выступаю в роли рецензента отдельных проектных решений и командных процессов. Иногда, при необходимости, включаюсь в прямое управление и разработку, но стараюсь этого избегать. Недавно мне задали вопрос: "А что если аналитик не хочет решать управленческие задачи?" Я в свою очередь порекомендовал своему визави познакомится с содержанием соответствующего профессионального стандарта. С определенного времени, ссылки на соответствующие профессиональные стандарты я вписываю в трудовые договора своих сотрудников... Такая ссылка легитимно устраняет массу лишних вопросов... Так сказать, на берегу.... Однако многие руководители почему-то ограничивают полномочия своих сотрудников фантазиями чужих HR-специалистов публикуемыми на hh... Или думают, что решат все проблемы фразой в трудовом договоре о том, что "сотрудник должен выполнять все распоряжения руководителя"...
Результаты своих управленческих экспериментов над живыми людьми я иногда публикую на Хабре и на своем pet-проекте aimsmart.ru. Эти же статьи использую как неформальные, но вполне действующие, регламенты для своей проектной команды...
sergeytolkachyov
22.08.2024 06:25+1
Стили подправить...
aimfirst
22.08.2024 06:25Спасибо, поправлю! Что скажешь... Сеанс кодотерапии выровнял кривые руки РП, исковерканные менеджментом, не до конца... ;)
peterzh Автор
22.08.2024 06:25Спасибо. У меня в списке статей в блокнотике есть проект статьи под названием "РП администратор или РП помощник", надо будет ввернуть эту неприятную для некоторых новость. Я в свое время болезненно воспринимал то, что я отвечаю вообще за все косяки на моем проекте.
uuger
Нефункциональные требования в ТЗ не включаем, значит? А вы точно РП?
Samhuawei
РП не будет участвовать в 400 собеседованиях. Это HR которому спихнули список вопросов и примерных ответов.
peterzh Автор
Зря вы так, другие мои статьи почитайте.
Я примерно каждый год выходил на рынок - просто интересно его было исследовать + ищу сам давно и много. Да, местами я работаю как HR, когда HR у меня нет, но это не мой профиль
savva_lisicinskii
по-моему для 15 лет опыта собеседований это абсолютно адекватная цифра
peterzh Автор
Да, точно. на небольших проектах NFR как правило не пишут. Или пишут одной строчкой.
Если вы джуна спросите про нефункциональные требования к системе, он, скорее всего, поломается. Если он отвечает бодро - я бы советовал брать.
uuger
осмелюсь напомнить, что, например, архитектура системы - это нефункциональное требование.
чем собрался управлять этот самый РП, когда у него нет понимания сколько "железа" ему надо и каким стеком будут реализовываться функциональные требования? Лицензии, требования к доступности, безопасности? Человек, который это не пропишет "на берегу" тянет, в лучшем случае, на стажера. А ещё лучше - пару лет администратором проекта посидеть, поработать с документами.
peterzh Автор
Ну тут я бы и сам с вами поспорил. Архитектура системы - это результат исполнения функциональных и нефункциональных требований.
a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.[1]
Давайте для начала: речь идет про джуна. Если джуна поставить рулить проектом, где есть хорошие NFR (кроме времени отклика системы), скорее всего, он проект завалит. Туда надо искать другого сотрудника, а этого обучать на проектах попроще (развитие того, что уже существует).
Про администратора - так можно. Но надо же кого то обучать :)