Все равно не убедили в том, что ходить в горы = проект.
Я настаиваю, что это "процесс".
Если проект - это достижение УНИКАЛЬНОЙ измеримой уместной цели в ограничениях по времени и ресурсам,
то процесс - это воспроизведение того, что уже делалось ранее, в конкретных ограничениях. Есть входы, выходы, механизм и контроль.
И, да - процесс тоже можно зафакапить, как и проект, если косячит руководитель. То есть ваша история - что руководитель бросил группу и тем самым сломал проект, правильнее читать что у правильного процесса убрали управление и он сломался.
Аргументирую ещё раз по вашему примеру:
Берем классическую процессную ICOM-модель с процессом "ходить в горы":
Input - вход. Мы запускаем процесс с определенной группой на определенную гору и конкретное время сезона (вроде это важно).
C - Control: ходить в горы это формализованная история. Как вы говорите - горы ошибок не прощают, а правила писаны кровью. Вот эти самые правила - это не проектные ограничения, а контроль процесса. Нарушили их - процесс сломался.
O - Output - Выход этого процесса: факт прохождения по маршруту полной группой живыми и здоровыми. При этом если контроль (правила) мешают подняться на вершину - то это не так важно, как вернуться домой живыми и здоровыми.
M - Mechanism. Механизм - это руководитель группы. Он обеспечивает, чтобы бы обеспечен выход процесса и соблюдались правила.
Отказ от восхождения на гору, если так сложились обстоятельства - это компенсация процесса (откат в безопасное состояние). Когда группа возвращается чтобы выход сошелся.
Это процесс - потому, что вы делаете то, что это уже кто-то делал. Так или иначе. Первое же правило проекта: Цель - уникальна == тут же ломается. Это не уникальная цель. Да, люди другие. Гора м.б. другая. Но вряд ли команда проекта пошла в горы вообще наобум без никакой подготовки. Вы не писали ТЗ тут по водопадной модели пытаясь прописать все US, UC и TC. И тем более не пошли в горы по гибкой методологии (Agile) с неясным способом достижения результата, но с понятной первой итерацией - когда наметили первый шаг, поднялись на 100 метров, провели ретроспективу, сделали выводы и пошли дальше ко второму шагу, накапливая экспертизу и опыт для каждого последующего шага.
И как я писал в самом начале: я не спорю со смыслом вашей статьи. Я лишь говорю - что пример с альпинизмом не удачен.
Как РПшник скажу, что бизнес - это всегда про риски сроков и денег. Большое и сложное решение которое якобы решает проблему бизнеса. Но на деле риск просрать много сроков и денег.
Своим заказчикам я зачастую при релизы спрашиваю: вы хотите фичу для теста гипотезы? Или вы точно знаете что это вам нужно? Что вы от этого выиграете?
Если вам точно нужно именно это - то устроит ли вас быстрое решение для теста прямо сейчас "На троечку", или нужно всеобъемлющее и огромное вылизанное решение, но через 3-6 месяцев "на твердую пятерку"?
Как правило если речь идет не о ключевых фичах, о деньгах или потере данных - то соглашаются все на "Троечку" сейчас.
Оговорюсь - решение на "троечку" хороши только если, потом переделка этого не приведет к 2-ой, а то и тройной-четверной цене на переделку.
Например, если в будущем через год, два-три с решением "на троечку" потребуется изменить ядро системы или основной бизнес-процесс, то мы его перепишем под ключ, накатим кучу миграций, сформируем огромный теходолг переноса фич с момента релиза "фичи на троечку", да ещё и упоремся в тестирование на пофичное, регрессионное и нагрузочное.
Если уж совсем на пальцах: то решение на троечку - "это форма авторизации с емэйлом и паролем", которая умеет пускать пользователей по точному совпадению пары емэйл - пароль с тем что есть в СУБД с отсеканием SQL-инъекций. Ничего больше она не умеет.
Решение на 5+ - это форма с валидацией по маске почты, с подтверждением ящика на лету, возможностью перехода на регистрацию, если такого пароля нет в СУБД, с хранением данных в сессии браузера в шифрованном виде, и требованием по сложностью ввода пароля, который меряется с каждым новым введенным символом. ПРи этом еще и адаптивно и нативно для моб. устройств. Ну и пусть ещё все это вылизано на PixelPerfect задротство.
Иные заказчики порой сразу упарываются в такую вот форму авторизации, забывая - что это чисто утилитарная функция - дать или не дать доступ человеку в систему. Все основное и вкусное за этими воротами. Но решение "3" делается за полдня-день, а на "5+" можно недели или даже месяцы потратить. Хотя всего лишь форма в 2 поля и 3 кнопки, 1 BE-ручку.
Посыл - люди важнее сертификатов + верь глазам своим (не верь стороннему мнению) - верен.
Но пример считаю неудачным. РП и руководитель восхождения на гору - не одно и то же.
Задушнюсь: РП от не РП отличает осмысленный и осязаемый результат. То, что можно пощупать. Применимо к IT - тут ещё и про что результат проекта, полученный от ИТ, соответствует закрытию проекта от бизнеса (больше, лучше, сильнее с замером в граммах и деньгах). Руководитель восхождения на гору - это больше про хитровыдуманный процесс с качественной обработкой оперативных задач. Т.е. больше про путь, нежели результат.
Сравнивать РП с руководителем группы восхождения - все равно что сравнивать: тренера спортсмена, что хочет побить олимпийский рекорд, с режиссером театра, что хочет поставить крутую пьесу. Олимпийский рекорд - это конкретная цифра на часах. А крутая пьеса - это что угодно. От того, что нравится режиссеру лично или его маме до коммерческого успеха и аншлага в зале.
Не оч. удачное сравнение. Я когда читал, так и не понял: - а чем плохо, что только РГ поднялся на вершину а группа нет? Горы место опасное. И рисковать членами группы и их здоровьем чтобы добиться результата подъема всех на высоту - такое себе. Горы ошибок не прощают. А м.б. цель группы была и вовсе научиться навыкам восхождения и вернуться домой живой. Тогда вершина тут вовсе не при чем. Туда же - если цель просто получить красивые фоточки вокруг. На мой обывательский взгляд (я в горы не хожу) - цель горного альпинизма: "Забраться настолько высоко, насколько можно, чтобы была возможность безопасно и в полном составе вернуться обратно". Поэтому натягивая метафору на управление проектами - тут такое не катит, если только цель проекта - не проверить гипотезу пилотом.
Суть мессенджа автор - вы правильно указали. Чтобы людям решать межличностные проблемы и конфликты - нужно душнить и проговаривать все детально. Иначе есть альтернатива, что все останется так как есть - а ситуация случится так, как случится (решение на букву "С" - Смирись).
Мое субъективное мнение по статье: мне не хватило немного глубины. Хотя бы в 1 из кейсов.
А именно: почему человек сам не додумался обсудить все?
Т.е. я ставлю под сомнение реальность вашего тезиса - проблемы:
Люди страдают на работе и в отношениях, потому что не говорят "словами через рот". Потому что не умеют/не догадались.
КМК тут правильнее смысл:
Почему люди молчат (и не говорят "словами через рот")? Потому что не могут или потому что не хотят или потому что любят страдать или потому, что боятся последствий == не готовы принять на себя ответственность, что в случае фейла в попытке - это будет их проблема или даже возникнут какие-то новые?
Вот эта аналитика была бы бриллиантом в этой статье.
Но мое имхо: люди не говорят словами через рот - потому что любят страдать и боятся высунуться. Такая вот у нас дурацкая ментальность. Сказать людям что-то и разобраться - страшнее, чем оставить проблему здесь и сейчас нерешенной.
"Авось как нибудь само разрулится. А нет - ну так нет. Не судьба. " (метасообщение = еще одни посредственные людишки меня не оценили по должному. А че это я должен решать их проблемы за них? Пусть как нибудь сами догадаются и разрулят).
Но чтоб решение межличностных конфликтов нормально заработало - нужно объективно доказать, почему не решение проблемы здесь и сейчас ХУЖЕ чем оставить её тлеть с надеждой, что это самой по себе разрулится? Почему людям нужно брать ответственность и начать говорить? Почему это лучше чем просто молчать?
В ваших кейсах - этого не видно. Ну уволился, так уволился. Люди приходят и уходят. Это разве и правда проблема? А для кого? а почему? ==> я к тому, что чтобы ваша статья заработала - нужно по сути предельно понятно почему молчать о проблемах хуже, чем говорить. Так чтобы до каждого это дошло даже в его уникально-локальной жизни.
С позиции разбора кейсов - соглашусь. В идеальном мире норм руководители должны работать так, как вы и написали.
Но на практике - увы, это редкость. Я думаю, если устроить тут перекличку: на "у кого нормальный / не нормальный руководитель - рассчитайсь", то явно перевесят не нормальные руководители. ==> следствие "Надо работать с тем, что есть". Ну либо очень сильно искать и надеяться на удачу, что вам повезет найти нормального босса.
Общий тезис статьи автора "что то вас парит - скажите ртом" ==> Не заставляйте людей догадываться (не догадаются), надеяться на предугадывание ваших чувств (не сработает. Люди не экстрасенсы) ==> все же верен.
Отмечу, что автор по тексту статьи намекал - что этот тезис не только про работу, но и про личные отношения вне нее, но примеров не привел. И это так же справедливо.
Я - руководитель проектного офиса (глава РПшников). Мой опыт в собеседовании кандидатов около 40-50 проведенных собеседований.
Я убежден, что помимо хардов так же капец как важны софты. А именно на пальцах: если человек закусился на работу пусть даже в новой профессии для него - то он добьется успеха.
История 1. Найм в небольшой компании (30-35 человек).
В прошлом делал ставку на двух кандидатов, что пришли в разработку: девочка на почте, выдающей посылки и только из декрета, и мальчик-менеджер по производству мебели.
Если бы я оценивал их по стандартному и шаблонному описанию вакансий, то они бы были слиты на этапе резюме. HR-а тогда не было. И я тогда еще РПшник сам их оценивал.
Пусть не по закону, но они делали тогда у меня 10 тестовых заданий, каждое из которых у них съело до 3-4 месяцев общего времени, с учетом правок. Девочка мне отдельные задания переделывала раз 5. В плане хардов, повторюсь, были слабые. Поэтому отправлял их гуглить, кидал примеры, проверял и давал качественную (как мне кажется) ОС с конкретикой почему это плохо и на что повлияет.
После я убедил директора, что их стоит взять. Да они слабы технически. Но их упорству и ответственности стоит позавидовать.
А спустя год - им дали внутренние награды "Лучший фронт/бек разработчик" в компании. Конкуренция внутренняя - 10 человек на награду.
Мораль: я ставил на то, что человек постоянно стремится к совершенству. И реально учится. Но думается мне, заставь сейчас кандидатов делать тестовые задания бесплатно да ещё переделывать, то начнется нытье про беспредел нанимающих, да ещё что за это деньги не делается. ИМХО - айтишка - это не про легкость работы. Если ты хочешь в нее перейти - велкам, но надо пахать как папа Карло.
История 2. Собеседования в аутстафф компании.
Аутстафф компания - дает своих людей в аренду заказчикам. Для этого проводится собеседования, которые проводят HR-ы заказчика и тех. специалисты позже.
Компания, где работал, получила много отказов. Хотя по хардам Руководители отделов своих чад учили, готовили и прям натаскивали. ИТ-шники сливались не на вызубренной теории или практике (А ля leetcode). А просто потому что "Он умный. Просто поплыл на неожиданных вопросах. Да и переволновался" (с) Руки отделов.
На практике же анализ показал, что люди просто не умеют себя показать в нормальном свете. На собесах эти люди:
сидели в майках алкоголичках с бокалами непонятного напитка;
общались в людных местах, где их не слышно из-за гомона вокруг;
читали свои ответы с экрана или блокнота (это прям видно - да).
не способны были немного порассуждать самостоятельно (шаг влево-вправо от резюме - и человек сыпется. Возникает вопрос: он реально спец или просто натренирован по написанному кем-то резюме).
Курили в камеру или чесались ковырялись в своих "Технологических отверстиях".
Да, это все про субъективщину. Но представьте ситуацию с другой стороны - вы пришли нанять электрика в свою квартиру по перепрокладке кабелей по всей квартире. Работа важная. А вас встречает нечто с этими вот признаками выше. Вы будете с ним общаться дальше и дойдете до осмотра сделанных им объектов реально? Это ведь неприятный человек с виду. Надо себя пересилить, чтобы судить по результату, а не "обертке".
Чтобы подготовить людей к таким вот собесам пришлось людям писать инструкцию: как подготовиться, как выглядеть, что должно быть тихо, что важен внешний вид и пить лучше только воду, если от страха во рту пересохло. И что нормально говорить, если вам нужно время подумать или порассуждать вслух. Это не плохо - а просто нормально.
А чтобы убедиться, что уроки усвоены, и что человек не поплывет на чуть более сложном вопросе по хардам, приходилось выбивать человека из чувства равновесия нетипичными вопросами из жизни и мира вокруг. А ля:
Как при помощи кирпича и веревки узнавать погоду (гуглите эту шутку);
Если есть окружность Земли и вокруг нее есть ещё одна окружность, длина которой больше длины окружности земли на 1 метр, то пролезет ли мышка в такую окружность (попробуйте прикинуть сами. Гуглить формулы, размеры - не запрещается).
Я - дачник. Хочу смонтировать дома систему водополива в теплице летом, чтобы капельный полив включался либо по расписанию, либо по пороговому значению относительной влажности. С чего мне надо начать тут? (это не сложно тут порассуждать. Любой ответ что опишет порядок действий - уже хорош).
Мораль: когда все резюме как под копирку. Когда их формат навязан hh и проч. подобными сервисами. Когда люди натаскались на типовых вопросах - как понять, кто из них стоящий? А кто нет? Сказать: я - ответственный и нацеленный результат == херня. Можно набрехать с три короба. А как проверить это реально в рамках резюме или собеса?
З.ы. сейчас я при найме смотрю: резюме на опыт в смежных областях, на целевые навыки, что соответствуют портрету должности (этот портрет есть у HR). Там нет никакой магии или экзотики - просто базовые знания в профессии. На собеседованиях - я больше люблю в вопросы ситуации. Быстро и наглядно дают понять кто есть кто. Да это тоже моя субъективщина. Нет я не учился оценивать людей. Скорее сам учусь в процессе до сих пор.
Эпилог: рынок сейчас и правда сломан. Много есть субъективного. С одной стороны все прозрачно и как под копирку. НО когда пачки однотипных резюме - нужны способы быстро отсеивать врунишек, натасканных и просто неадекватов. Трудяги и те, что могут сами включить голову на резюме - это просто бриллианты сейчас.
Закину тут удочку - что фактически нет ведь такой школы или инструмента для обучения этим компетенциям. Он как то слабо описан. И изучается методом тыка в муках
Арррр... ну что ж вы в самом деле - какие-то сапожники без сапог.
Поясняю:
Обычно продукты и проекты растут итерационно через проверку гипотез, фокус-группы и описание ИКР (идеальный конечных результатов).
Вы так работаете: взяли идею, прикинули ИКР, выписали из этого MVP, сделали, проверили, накинули мысли с ретро, пошли в след. итерацию. И так далее, и тому подобное.
Что ж вы свои РАБОЧИЕ операционные и проектные дела не делаете так же?
Это такой же проект ведь по сути.
Поясню на пальцах: процесс - это ОПИСАНИЕ того, что уже РАБОТАЕТ. Его фишка в том, что вы документируете то, что РАБОТАЕТ так, КАК ВАМ НУЖНО. С хрена ли вы решили, что способны придумать процесс, который сразу заработает? Процессы как феномен - нужны если вам нужно сделать человеконезависимые задачи, ЛИБО если требуется масштабирование успешного опыта. Условно - если ваш Вася Пупкин кто умеет круто раскатывать релизы на прод - уволится, заболеет или умрет, то ваша работа встанет. Т.к. только он может в крутую раскатку. А чтоб нащупать этот способ пройдет время. Вот вы и документируете опыт Васи в процессе. Чтоб условно любой человек со схожими компетенциями мог в такую же работу с таким же результатом. Процесс - это про воспроизводимость действий.
Но если вы что-то делаете впервые. Если вы не знаете точно выстрелит ли это точно или нет - вам нужен проект. Это про ограничения, про критерии качества выполнения работ, про зоны ответственности ЗА ТАКОЙ ЭКСПЕРИМЕНТ.
Соглашусь тут с автором, что важна определенная зрелось в компании. Это задачи про преемственность опыта, отработку ошибок, ретроспективный взгляд на проходящие и достижение целей.
Пока компания растет (есть признаки) или развивается - ей не до процессов. Важна скорость. Поэтому куча решений принимается в моменте, экспериментально, на свой страх и риск.
Соответственно - для молодой компании - нормально, если её деятельность это одни проекты, и никаких процессов.
Но когда компания замедлила рост, задалась вопросами а можно ли делать эффективнее то, что уже есть и стабильно генерирует прибыль или дает результат, или нам нужно идти в масштабирование на другой город, другой офис и других людей исполнителей - то вот тут уже и нужны процессы. При чем сперва описанные как есть. А потом (тривиально) to be.
Мораль:
зря вы полезли описывать то, чего нет. Вам бы проектик сперва запустить для теста идей да гипотез. Чтобы найти способ как это заработает и погонять пару месяцев.
Да, эту статью я уже прочел. Вчера, если честно. Когда пошел изучать ссылки.
И вы, безусловно, правы - что дело в том, кто не смог решить проблему. А не в абстрактных "чудаках" на букву М.
Т.е. основная проблема всего этого хождения по мукам в том, что тот кто МОЖЕТ решить проблему, НЕ СМОГ УБЕДИТЬ остальных заинтересантов проблемы в том, как лучше сделать эту задачу.
Ну или точнее: примерно половина бизнес-идей отвергаются на этапе генерации идеи инициативными и неравнодушными сотрудниками.
Симптомы: у топов бизнеса нет 8-10 часов в месяц чтобы заслушивать и вникать в варианты решения идей, описанных технарями.
Технари не могут кратко и ёмко (буквально в паре предложений) пояснить бизнесу в чем ценность наращивания серверов (обычно говорят, ну будет быстрее все работать. Или мы одновременно сможем запускать 2-3 проекта за раз. Бизнес говорит "и че?" или "А я тут при чем?" и все рушится)
От себя добавлю - это вообще общая проблема большинства людей, с кем я работал.
Вместо ответа на вопрос: "что ты хочешь от человека и для чего?" с ответами на вопросы потом (уточнение деталей) начинается все издалека с кучей преамбул и предисловий, потом подводка с оговорками и вариантами, наконец проблема с эмоционально окрашенной и нечеткой выгодой ("Ну будет лучше. Мы ж вам вся рассказали"). Спойлер - бизнес уснул ещё на этапе преамбулы. И не помнит/не понял что ему там втирали полчаса.
ИТ хочет от бизнеса работы по нужным ИТ сценариям;
Бизнес так работать не хочет, мол, нам и так все норм. Вы главное делайте то, что мы вам говорит.
ОР: этой состыковки - описание той проблемы, которая есть за симптомами (отказы бизнесу на проверки бизнес-гипотез, т.к. не выделено денег на это, потому что акционерам не передана нужная инфа, которую стоит собирать по ИТ-сценариям)
Следствие этого = бизнес не доволен работой ИТ - считает, что ИТ саботирует их запросы и не хочет работать.
И мы как раз таки ходим по кругу: бизнес хочет что-то новое - ИТ пытается понять за чей счет правки - инвесторы не понимают зачем на это тратить деньги - ИТ просит сделать все по правилам - Бизнес отказывается - ИТ отказывает в помощи бизнесу- Бизнес недоволен.
Найти и взять ряд метрик, по которым нужно делать контроль. Понять скорость опроса метрик (ежедневно, еженедельно и т.д.)
Исходя из этого делаем процессы и роли. Роль - это про ответ на вопрос, кто может дать результат. Обычно это роль - генератора вариантов решений, принимающий решения + фактический исполнитель (руки). Иногда генератор да руки - это один и тот же человек.
Запускаем процессы и проверяем как работают метрики. Все ли наглядно и понятно.
Делаем PDCA цикл по процессам и ролям. В смысле регулярный пересмотр, анализ и сбор обратной связи.
Правило: принятые правила игры (процессы + роли) в процессе выполнения не оспариваются. Но их можно менять в фиксированных точках. И вот в этих фиксированных точках можно генерировать идеи, слушать людей, проводить SWOT-анализы. Основной ответ с таких встреч - мы оставляем все как есть или меняем на что-то. Если меняем то кто когда как и где делает и перед кем как часто отчитывается.
Соглашусь с болью души автора. Это реально проблема и боль.
В России к сожалению до сих пор жива и жиза шутейка:
Кто умеет работать - работает.
Кто не умеет работать - идет учить.
Кто не умеет ни работать, ни учить - идет руководить.
Это порочная история, т.к. менеджмент - это реально сложная дисциплина. Но она часто привлекает людей, кто приходит почесать ЧСВ либо тех, кто хочет тупо денег.
Тогда для решения боли автора есть два фундаментальных решения:
либо сделать бизнес из профессиональных решателей/закрывателей IT-проектов;
либо сделать институт, который позволяет фильтровать и обучать руководителей среднего звена на каких то типовых задачах из жизни.
К слову мне самому для моей деятельности хотелось бы и в то, и в другое залезть как организатор/руководитель/участник. Благо база менеджмента (по заветам IPMA/PMI) и преподавания (читал лекции в ВУЗах) у меня есть.
Если есть тут единомышленники или желающие помочь - черканите в треде. Мне нужен человек с опытом, кто знает как быстро тестировать бизнес-гипотезы. Первый шаг - где найти клиентов либо для бизнеса закрывателей проектов, либо для обучения РПшников среднего звена.
Спасибо автору за в целом справедливое и правильное (имхо) описание смысла постановок.
Статистически всего того, что есть в статье для типового проекта и среднего сотрудника (сферического в вакууме) достаточно.
Но как вредный и душный человек по сути - не могу ни вставить свои пять копеек. Простите =).
Данная статья полезна тем, кто хочет сам написать постановку впервые и не знает с чего начать. Тогда берет это за основу и вперед погнали.
Я сам ПМ. И работал на разных проектах. Ниже накидаю то, что видел на практике.
На практике (в реальных кейсах и реальных командах) всплывают разные кейсы:
постановки по такой структуре оцениваются на весьма большое число часов. И чем выше число часов - тем скорее всего не попадание факта в план оценки.
скиллов разработчиков не хватает для чтения многобуков и им бы что-то конкретнее да попроще, да декомпозированнее. На одном из моих проектов, например, такие постановки читали только тимлид, QA, PM да PO. Обычные разрабы спотыкались на первых же абзацах (пропускали детали постановки). Поэтому согласовывали с PO да заказчиками мы такие вот постановки, но на ЧТЗ на команду это не работало. Так например бэку нужно было больше инфы для воспроизводимости: стенд с фикс настройкой, предзаданные данные, отметка по ролевой модели (под кем должна была отрабатывать серверная логика) + спецификация по отработке ошибок + алгоритм расписанный на "пальцах" (рисовали в Миро или Excel). Фронтам же и ещё часто требуются ссылки на Ui kit, требовались пометки какой именно UI компонент юзать и с какими его настройками.
крч, такие постановки сильно человекозависимы. Способен их человек читать или понимать. Как ПМ первое что мы сделали с командой - это сделали соглашение кому и что надо видеть в постановке и договорились кто и как делает постановки да ЧТЗ. Из моего опыта - такие постановки как у автора - это для тимлидов, техлидов и QA пишутся аналитиком. А вот реальные задачи для трекера с декомпозицией - это уже лиды пишут из постановки на конкретно технарском языке (компоненты + ручки + состояния) и последовательность/зависимости нарезанных задач. Тогда можно играться в скрам и на стендапах это все отслеживать, чтоб не облажаться на тестировании да приемке задачи.
по сути разработчикам нужно видеть в постановке то, что нужно именно им для разработки. Отдельные пункты ЧТЗ и постановок от аналитики могут быть избыточными, или наоборот неполными. Прежде чем писать постановку стоит показать структуру типовой постановки конкретной команде и спросить все ли им хватает или не хватает по данному проекту. Обычно есть уточнения и пожелания.
Сюда еще накину такой смысл: в идеале постановки должны соответствовать зрелости команды и процессам компании. Отдельным людям достаточно просто направление, цель и задачи фичи дать - и они сами по красоте развернут все, быстро покажут на демо и доработают под конкретного заказчика. Другим достаточно ЧБ схематичного прототипа с типовым golden case (дальше они сами задолбают вопросами). Третьим же нужна чуть ли не пошаговая инструкция по шагам что, где и как надо изменить/добавить. Четвертым же сразу нужные ещё и тест-кейсы по которым будут написаны авто-тесты и под которые будут подгоняться реальные задачи на разработку.
Зарезюмирую: для старта написания постановок (если не знаешь как вообще) - крутой материал. Для практики - стоит учитывать реальных разрабов, заказчиков и команды.
Автору - мне бы было более ценно от вас услышать экзотические изменения в постановках, что требовались заказчикам или командам и зачем именно. Это если вдруг вы решитесь на ещё одну статью.
Дисклеймер: я хочу автору позадавать вопросы для более полной синхронизации с его месседжем. И, возможно. навести на новые мысли.
Автор, правильно ли я вас понял, что:
Вы делитесь своими субъективными переживаниями от собеседования кучи "специалистов" с неоправданно завышенными зарплатными ожиданиями? То бишь вам пригорело по итогу икс собеседований за период.
Вы старательно ищете на рынке кадры, которые вам будут идейно близки (задротство в терминах, а также четкое знание матчасти).
Правда мне не очень понятно как это поможет выполняемой функции системных аналитиков? А какая она основная функция системных аналитиков, кстати. Ну, по вашему мнению? Что является результатом работы аналитика? Без воды, желательно. Задача: описать результат работы аналитика в 2 предложениях.
Пояснение: я хочу понять каким образом четкое знание матчасти и терминов вяжется с ожиданиями результатов работы конкретного кадра. Например, если я ищу повара - меня интересуют какие блюда он умеет готовить и как быстро и качественно он это делает. А чтобы понять правду он говорит или нет - я дам ему задание приготовить одно из названных блюд. И оценю время, качество и вкус. А ещё посмотрю на подачу, состояние кухни после готовки и ошметки от ингредиентов. Надо ли при этом повару знать чем помидор отличается от свеклы и как их выращивают - вопрос. Это может быть точкой роста на перспективу по мере наработки статистики по продуктам.
Вы хотите немного почесать своё ЧСВ (своим опытом). Я тут без наезда. Это просто пирамида Маслоу - жажда признания (профессионализма).
Все равно не убедили в том, что ходить в горы = проект.
Я настаиваю, что это "процесс".
Если проект - это достижение УНИКАЛЬНОЙ измеримой уместной цели в ограничениях по времени и ресурсам,
то процесс - это воспроизведение того, что уже делалось ранее, в конкретных ограничениях. Есть входы, выходы, механизм и контроль.
И, да - процесс тоже можно зафакапить, как и проект, если косячит руководитель. То есть ваша история - что руководитель бросил группу и тем самым сломал проект, правильнее читать что у правильного процесса убрали управление и он сломался.
Аргументирую ещё раз по вашему примеру:
Берем классическую процессную ICOM-модель с процессом "ходить в горы":
Input - вход. Мы запускаем процесс с определенной группой на определенную гору и конкретное время сезона (вроде это важно).
C - Control: ходить в горы это формализованная история. Как вы говорите - горы ошибок не прощают, а правила писаны кровью. Вот эти самые правила - это не проектные ограничения, а контроль процесса. Нарушили их - процесс сломался.
O - Output - Выход этого процесса: факт прохождения по маршруту полной группой живыми и здоровыми. При этом если контроль (правила) мешают подняться на вершину - то это не так важно, как вернуться домой живыми и здоровыми.
M - Mechanism. Механизм - это руководитель группы. Он обеспечивает, чтобы бы обеспечен выход процесса и соблюдались правила.
Отказ от восхождения на гору, если так сложились обстоятельства - это компенсация процесса (откат в безопасное состояние). Когда группа возвращается чтобы выход сошелся.
Это процесс - потому, что вы делаете то, что это уже кто-то делал. Так или иначе. Первое же правило проекта: Цель - уникальна == тут же ломается. Это не уникальная цель. Да, люди другие. Гора м.б. другая. Но вряд ли команда проекта пошла в горы вообще наобум без никакой подготовки. Вы не писали ТЗ тут по водопадной модели пытаясь прописать все US, UC и TC. И тем более не пошли в горы по гибкой методологии (Agile) с неясным способом достижения результата, но с понятной первой итерацией - когда наметили первый шаг, поднялись на 100 метров, провели ретроспективу, сделали выводы и пошли дальше ко второму шагу, накапливая экспертизу и опыт для каждого последующего шага.
И как я писал в самом начале: я не спорю со смыслом вашей статьи. Я лишь говорю - что пример с альпинизмом не удачен.
Как РПшник скажу, что бизнес - это всегда про риски сроков и денег.
Большое и сложное решение которое якобы решает проблему бизнеса. Но на деле риск просрать много сроков и денег.
Своим заказчикам я зачастую при релизы спрашиваю: вы хотите фичу для теста гипотезы? Или вы точно знаете что это вам нужно? Что вы от этого выиграете?
Если вам точно нужно именно это - то устроит ли вас быстрое решение для теста прямо сейчас "На троечку", или нужно всеобъемлющее и огромное вылизанное решение, но через 3-6 месяцев "на твердую пятерку"?
Как правило если речь идет не о ключевых фичах, о деньгах или потере данных - то соглашаются все на "Троечку" сейчас.
Оговорюсь - решение на "троечку" хороши только если, потом переделка этого не приведет к 2-ой, а то и тройной-четверной цене на переделку.
Например, если в будущем через год, два-три с решением "на троечку" потребуется изменить ядро системы или основной бизнес-процесс, то мы его перепишем под ключ, накатим кучу миграций, сформируем огромный теходолг переноса фич с момента релиза "фичи на троечку", да ещё и упоремся в тестирование на пофичное, регрессионное и нагрузочное.
Если уж совсем на пальцах: то решение на троечку - "это форма авторизации с емэйлом и паролем", которая умеет пускать пользователей по точному совпадению пары емэйл - пароль с тем что есть в СУБД с отсеканием SQL-инъекций. Ничего больше она не умеет.
Решение на 5+ - это форма с валидацией по маске почты, с подтверждением ящика на лету, возможностью перехода на регистрацию, если такого пароля нет в СУБД, с хранением данных в сессии браузера в шифрованном виде, и требованием по сложностью ввода пароля, который меряется с каждым новым введенным символом. ПРи этом еще и адаптивно и нативно для моб. устройств. Ну и пусть ещё все это вылизано на PixelPerfect задротство.
Иные заказчики порой сразу упарываются в такую вот форму авторизации, забывая - что это чисто утилитарная функция - дать или не дать доступ человеку в систему. Все основное и вкусное за этими воротами. Но решение "3" делается за полдня-день, а на "5+" можно недели или даже месяцы потратить. Хотя всего лишь форма в 2 поля и 3 кнопки, 1 BE-ручку.
Посыл - люди важнее сертификатов + верь глазам своим (не верь стороннему мнению) - верен.
Но пример считаю неудачным. РП и руководитель восхождения на гору - не одно и то же.
Задушнюсь: РП от не РП отличает осмысленный и осязаемый результат. То, что можно пощупать. Применимо к IT - тут ещё и про что результат проекта, полученный от ИТ, соответствует закрытию проекта от бизнеса (больше, лучше, сильнее с замером в граммах и деньгах). Руководитель восхождения на гору - это больше про хитровыдуманный процесс с качественной обработкой оперативных задач. Т.е. больше про путь, нежели результат.
Сравнивать РП с руководителем группы восхождения - все равно что сравнивать: тренера спортсмена, что хочет побить олимпийский рекорд, с режиссером театра, что хочет поставить крутую пьесу. Олимпийский рекорд - это конкретная цифра на часах. А крутая пьеса - это что угодно. От того, что нравится режиссеру лично или его маме до коммерческого успеха и аншлага в зале.
Не оч. удачное сравнение. Я когда читал, так и не понял: - а чем плохо, что только РГ поднялся на вершину а группа нет? Горы место опасное. И рисковать членами группы и их здоровьем чтобы добиться результата подъема всех на высоту - такое себе. Горы ошибок не прощают. А м.б. цель группы была и вовсе научиться навыкам восхождения и вернуться домой живой. Тогда вершина тут вовсе не при чем. Туда же - если цель просто получить красивые фоточки вокруг. На мой обывательский взгляд (я в горы не хожу) - цель горного альпинизма: "Забраться настолько высоко, насколько можно, чтобы была возможность безопасно и в полном составе вернуться обратно". Поэтому натягивая метафору на управление проектами - тут такое не катит, если только цель проекта - не проверить гипотезу пилотом.
Как достичь такой магии? Только не говорите - что "Только в Хогвартсе"
Суть мессенджа автор - вы правильно указали. Чтобы людям решать межличностные проблемы и конфликты - нужно душнить и проговаривать все детально. Иначе есть альтернатива, что все останется так как есть - а ситуация случится так, как случится (решение на букву "С" - Смирись).
Мое субъективное мнение по статье: мне не хватило немного глубины. Хотя бы в 1 из кейсов.
А именно: почему человек сам не додумался обсудить все?
Т.е. я ставлю под сомнение реальность вашего тезиса - проблемы:
Люди страдают на работе и в отношениях, потому что не говорят "словами через рот". Потому что не умеют/не догадались.
КМК тут правильнее смысл:
Почему люди молчат (и не говорят "словами через рот")? Потому что не могут или потому что не хотят или потому что любят страдать или потому, что боятся последствий == не готовы принять на себя ответственность, что в случае фейла в попытке - это будет их проблема или даже возникнут какие-то новые?
Вот эта аналитика была бы бриллиантом в этой статье.
Но мое имхо: люди не говорят словами через рот - потому что любят страдать и боятся высунуться. Такая вот у нас дурацкая ментальность. Сказать людям что-то и разобраться - страшнее, чем оставить проблему здесь и сейчас нерешенной.
"Авось как нибудь само разрулится. А нет - ну так нет. Не судьба. " (метасообщение = еще одни посредственные людишки меня не оценили по должному. А че это я должен решать их проблемы за них? Пусть как нибудь сами догадаются и разрулят).
Но чтоб решение межличностных конфликтов нормально заработало - нужно объективно доказать, почему не решение проблемы здесь и сейчас ХУЖЕ чем оставить её тлеть с надеждой, что это самой по себе разрулится? Почему людям нужно брать ответственность и начать говорить? Почему это лучше чем просто молчать?
В ваших кейсах - этого не видно. Ну уволился, так уволился. Люди приходят и уходят. Это разве и правда проблема? А для кого? а почему? ==> я к тому, что чтобы ваша статья заработала - нужно по сути предельно понятно почему молчать о проблемах хуже, чем говорить. Так чтобы до каждого это дошло даже в его уникально-локальной жизни.
С позиции разбора кейсов - соглашусь. В идеальном мире норм руководители должны работать так, как вы и написали.
Но на практике - увы, это редкость. Я думаю, если устроить тут перекличку: на "у кого нормальный / не нормальный руководитель - рассчитайсь", то явно перевесят не нормальные руководители. ==> следствие "Надо работать с тем, что есть". Ну либо очень сильно искать и надеяться на удачу, что вам повезет найти нормального босса.
Общий тезис статьи автора "что то вас парит - скажите ртом" ==> Не заставляйте людей догадываться (не догадаются), надеяться на предугадывание ваших чувств (не сработает. Люди не экстрасенсы) ==> все же верен.
Отмечу, что автор по тексту статьи намекал - что этот тезис не только про работу, но и про личные отношения вне нее, но примеров не привел. И это так же справедливо.
А вот тут соглашусь полностью. Не добавить, не убавить. Спасибо
Я - руководитель проектного офиса (глава РПшников). Мой опыт в собеседовании кандидатов около 40-50 проведенных собеседований.
Я убежден, что помимо хардов так же капец как важны софты. А именно на пальцах: если человек закусился на работу пусть даже в новой профессии для него - то он добьется успеха.
История 1. Найм в небольшой компании (30-35 человек).
В прошлом делал ставку на двух кандидатов, что пришли в разработку: девочка на почте, выдающей посылки и только из декрета, и мальчик-менеджер по производству мебели.
Если бы я оценивал их по стандартному и шаблонному описанию вакансий, то они бы были слиты на этапе резюме. HR-а тогда не было. И я тогда еще РПшник сам их оценивал.
Пусть не по закону, но они делали тогда у меня 10 тестовых заданий, каждое из которых у них съело до 3-4 месяцев общего времени, с учетом правок. Девочка мне отдельные задания переделывала раз 5. В плане хардов, повторюсь, были слабые. Поэтому отправлял их гуглить, кидал примеры, проверял и давал качественную (как мне кажется) ОС с конкретикой почему это плохо и на что повлияет.
После я убедил директора, что их стоит взять. Да они слабы технически. Но их упорству и ответственности стоит позавидовать.
А спустя год - им дали внутренние награды "Лучший фронт/бек разработчик" в компании. Конкуренция внутренняя - 10 человек на награду.
Мораль: я ставил на то, что человек постоянно стремится к совершенству. И реально учится. Но думается мне, заставь сейчас кандидатов делать тестовые задания бесплатно да ещё переделывать, то начнется нытье про беспредел нанимающих, да ещё что за это деньги не делается. ИМХО - айтишка - это не про легкость работы. Если ты хочешь в нее перейти - велкам, но надо пахать как папа Карло.
История 2. Собеседования в аутстафф компании.
Аутстафф компания - дает своих людей в аренду заказчикам. Для этого проводится собеседования, которые проводят HR-ы заказчика и тех. специалисты позже.
Компания, где работал, получила много отказов. Хотя по хардам Руководители отделов своих чад учили, готовили и прям натаскивали. ИТ-шники сливались не на вызубренной теории или практике (А ля leetcode). А просто потому что "Он умный. Просто поплыл на неожиданных вопросах. Да и переволновался" (с) Руки отделов.
На практике же анализ показал, что люди просто не умеют себя показать в нормальном свете. На собесах эти люди:
сидели в майках алкоголичках с бокалами непонятного напитка;
общались в людных местах, где их не слышно из-за гомона вокруг;
читали свои ответы с экрана или блокнота (это прям видно - да).
не способны были немного порассуждать самостоятельно (шаг влево-вправо от резюме - и человек сыпется. Возникает вопрос: он реально спец или просто натренирован по написанному кем-то резюме).
Курили в камеру или чесались ковырялись в своих "Технологических отверстиях".
Да, это все про субъективщину. Но представьте ситуацию с другой стороны - вы пришли нанять электрика в свою квартиру по перепрокладке кабелей по всей квартире. Работа важная. А вас встречает нечто с этими вот признаками выше. Вы будете с ним общаться дальше и дойдете до осмотра сделанных им объектов реально? Это ведь неприятный человек с виду. Надо себя пересилить, чтобы судить по результату, а не "обертке".
Чтобы подготовить людей к таким вот собесам пришлось людям писать инструкцию: как подготовиться, как выглядеть, что должно быть тихо, что важен внешний вид и пить лучше только воду, если от страха во рту пересохло. И что нормально говорить, если вам нужно время подумать или порассуждать вслух. Это не плохо - а просто нормально.
А чтобы убедиться, что уроки усвоены, и что человек не поплывет на чуть более сложном вопросе по хардам, приходилось выбивать человека из чувства равновесия нетипичными вопросами из жизни и мира вокруг. А ля:
Как при помощи кирпича и веревки узнавать погоду (гуглите эту шутку);
Если есть окружность Земли и вокруг нее есть ещё одна окружность, длина которой больше длины окружности земли на 1 метр, то пролезет ли мышка в такую окружность (попробуйте прикинуть сами. Гуглить формулы, размеры - не запрещается).
Я - дачник. Хочу смонтировать дома систему водополива в теплице летом, чтобы капельный полив включался либо по расписанию, либо по пороговому значению относительной влажности. С чего мне надо начать тут? (это не сложно тут порассуждать. Любой ответ что опишет порядок действий - уже хорош).
Мораль: когда все резюме как под копирку. Когда их формат навязан hh и проч. подобными сервисами. Когда люди натаскались на типовых вопросах - как понять, кто из них стоящий? А кто нет? Сказать: я - ответственный и нацеленный результат == херня. Можно набрехать с три короба. А как проверить это реально в рамках резюме или собеса?
З.ы. сейчас я при найме смотрю: резюме на опыт в смежных областях, на целевые навыки, что соответствуют портрету должности (этот портрет есть у HR). Там нет никакой магии или экзотики - просто базовые знания в профессии. На собеседованиях - я больше люблю в вопросы ситуации. Быстро и наглядно дают понять кто есть кто. Да это тоже моя субъективщина. Нет я не учился оценивать людей. Скорее сам учусь в процессе до сих пор.
Эпилог: рынок сейчас и правда сломан. Много есть субъективного. С одной стороны все прозрачно и как под копирку. НО когда пачки однотипных резюме - нужны способы быстро отсеивать врунишек, натасканных и просто неадекватов. Трудяги и те, что могут сами включить голову на резюме - это просто бриллианты сейчас.
Спасибо за честность
Да, рад услышать про релевантный опыт.
Закину тут удочку - что фактически нет ведь такой школы или инструмента для обучения этим компетенциям. Он как то слабо описан. И изучается методом тыка в муках
Арррр... ну что ж вы в самом деле - какие-то сапожники без сапог.
Поясняю:
Обычно продукты и проекты растут итерационно через проверку гипотез, фокус-группы и описание ИКР (идеальный конечных результатов).
Вы так работаете: взяли идею, прикинули ИКР, выписали из этого MVP, сделали, проверили, накинули мысли с ретро, пошли в след. итерацию. И так далее, и тому подобное.
Что ж вы свои РАБОЧИЕ операционные и проектные дела не делаете так же?
Это такой же проект ведь по сути.
Поясню на пальцах: процесс - это ОПИСАНИЕ того, что уже РАБОТАЕТ. Его фишка в том, что вы документируете то, что РАБОТАЕТ так, КАК ВАМ НУЖНО. С хрена ли вы решили, что способны придумать процесс, который сразу заработает? Процессы как феномен - нужны если вам нужно сделать человеконезависимые задачи, ЛИБО если требуется масштабирование успешного опыта. Условно - если ваш Вася Пупкин кто умеет круто раскатывать релизы на прод - уволится, заболеет или умрет, то ваша работа встанет. Т.к. только он может в крутую раскатку. А чтоб нащупать этот способ пройдет время. Вот вы и документируете опыт Васи в процессе. Чтоб условно любой человек со схожими компетенциями мог в такую же работу с таким же результатом. Процесс - это про воспроизводимость действий.
Но если вы что-то делаете впервые. Если вы не знаете точно выстрелит ли это точно или нет - вам нужен проект. Это про ограничения, про критерии качества выполнения работ, про зоны ответственности ЗА ТАКОЙ ЭКСПЕРИМЕНТ.
Соглашусь тут с автором, что важна определенная зрелось в компании. Это задачи про преемственность опыта, отработку ошибок, ретроспективный взгляд на проходящие и достижение целей.
Пока компания растет (есть признаки) или развивается - ей не до процессов. Важна скорость. Поэтому куча решений принимается в моменте, экспериментально, на свой страх и риск.
Соответственно - для молодой компании - нормально, если её деятельность это одни проекты, и никаких процессов.
Но когда компания замедлила рост, задалась вопросами а можно ли делать эффективнее то, что уже есть и стабильно генерирует прибыль или дает результат, или нам нужно идти в масштабирование на другой город, другой офис и других людей исполнителей - то вот тут уже и нужны процессы. При чем сперва описанные как есть. А потом (тривиально) to be.
Мораль:
зря вы полезли описывать то, чего нет. Вам бы проектик сперва запустить для теста идей да гипотез. Чтобы найти способ как это заработает и погонять пару месяцев.
И лишь тогда в процессы идти.
З.з.ы. Это мое имхо. Без обид, пожалуйста.
Да, эту статью я уже прочел. Вчера, если честно. Когда пошел изучать ссылки.
И вы, безусловно, правы - что дело в том, кто не смог решить проблему. А не в абстрактных "чудаках" на букву М.
Т.е. основная проблема всего этого хождения по мукам в том, что тот кто МОЖЕТ решить проблему, НЕ СМОГ УБЕДИТЬ остальных заинтересантов проблемы в том, как лучше сделать эту задачу.
Ну или точнее: примерно половина бизнес-идей отвергаются на этапе генерации идеи инициативными и неравнодушными сотрудниками.
Симптомы: у топов бизнеса нет 8-10 часов в месяц чтобы заслушивать и вникать в варианты решения идей, описанных технарями.
Технари не могут кратко и ёмко (буквально в паре предложений) пояснить бизнесу в чем ценность наращивания серверов (обычно говорят, ну будет быстрее все работать. Или мы одновременно сможем запускать 2-3 проекта за раз. Бизнес говорит "и че?" или "А я тут при чем?" и все рушится)
От себя добавлю - это вообще общая проблема большинства людей, с кем я работал.
Вместо ответа на вопрос: "что ты хочешь от человека и для чего?" с ответами на вопросы потом (уточнение деталей) начинается все издалека с кучей преамбул и предисловий, потом подводка с оговорками и вариантами, наконец проблема с эмоционально окрашенной и нечеткой выгодой ("Ну будет лучше. Мы ж вам вся рассказали"). Спойлер - бизнес уснул ещё на этапе преамбулы. И не помнит/не понял что ему там втирали полчаса.
Спасибо, было полезно.
Прям сейчас решаю задачу состыковать:
ИТ хочет от бизнеса работы по нужным ИТ сценариям;
Бизнес так работать не хочет, мол, нам и так все норм. Вы главное делайте то, что мы вам говорит.
ОР: этой состыковки - описание той проблемы, которая есть за симптомами (отказы бизнесу на проверки бизнес-гипотез, т.к. не выделено денег на это, потому что акционерам не передана нужная инфа, которую стоит собирать по ИТ-сценариям)
Следствие этого = бизнес не доволен работой ИТ - считает, что ИТ саботирует их запросы и не хочет работать.
И мы как раз таки ходим по кругу: бизнес хочет что-то новое - ИТ пытается понять за чей счет правки - инвесторы не понимают зачем на это тратить деньги - ИТ просит сделать все по правилам - Бизнес отказывается - ИТ отказывает в помощи бизнесу- Бизнес недоволен.
Найти и взять ряд метрик, по которым нужно делать контроль. Понять скорость опроса метрик (ежедневно, еженедельно и т.д.)
Исходя из этого делаем процессы и роли. Роль - это про ответ на вопрос, кто может дать результат. Обычно это роль - генератора вариантов решений, принимающий решения + фактический исполнитель (руки). Иногда генератор да руки - это один и тот же человек.
Запускаем процессы и проверяем как работают метрики. Все ли наглядно и понятно.
Делаем PDCA цикл по процессам и ролям. В смысле регулярный пересмотр, анализ и сбор обратной связи.
Правило: принятые правила игры (процессы + роли) в процессе выполнения не оспариваются. Но их можно менять в фиксированных точках. И вот в этих фиксированных точках можно генерировать идеи, слушать людей, проводить SWOT-анализы. Основной ответ с таких встреч - мы оставляем все как есть или меняем на что-то. Если меняем то кто когда как и где делает и перед кем как часто отчитывается.
Соглашусь с болью души автора. Это реально проблема и боль.
В России к сожалению до сих пор жива и жиза шутейка:
Кто умеет работать - работает.Кто не умеет работать - идет учить.Кто не умеет ни работать, ни учить - идет руководить.Это порочная история, т.к. менеджмент - это реально сложная дисциплина. Но она часто привлекает людей, кто приходит почесать ЧСВ либо тех, кто хочет тупо денег.
Тогда для решения боли автора есть два фундаментальных решения:
либо сделать бизнес из профессиональных решателей/закрывателей IT-проектов;
либо сделать институт, который позволяет фильтровать и обучать руководителей среднего звена на каких то типовых задачах из жизни.
К слову мне самому для моей деятельности хотелось бы и в то, и в другое залезть как организатор/руководитель/участник. Благо база менеджмента (по заветам IPMA/PMI) и преподавания (читал лекции в ВУЗах) у меня есть.
Если есть тут единомышленники или желающие помочь - черканите в треде. Мне нужен человек с опытом, кто знает как быстро тестировать бизнес-гипотезы. Первый шаг - где найти клиентов либо для бизнеса закрывателей проектов, либо для обучения РПшников среднего звена.
Спасибо автору за в целом справедливое и правильное (имхо) описание смысла постановок.
Статистически всего того, что есть в статье для типового проекта и среднего сотрудника (сферического в вакууме) достаточно.
Но как вредный и душный человек по сути - не могу ни вставить свои пять копеек. Простите =).
Данная статья полезна тем, кто хочет сам написать постановку впервые и не знает с чего начать. Тогда берет это за основу и вперед погнали.
Я сам ПМ. И работал на разных проектах. Ниже накидаю то, что видел на практике.
На практике (в реальных кейсах и реальных командах) всплывают разные кейсы:
постановки по такой структуре оцениваются на весьма большое число часов. И чем выше число часов - тем скорее всего не попадание факта в план оценки.
скиллов разработчиков не хватает для чтения многобуков и им бы что-то конкретнее да попроще, да декомпозированнее. На одном из моих проектов, например, такие постановки читали только тимлид, QA, PM да PO. Обычные разрабы спотыкались на первых же абзацах (пропускали детали постановки). Поэтому согласовывали с PO да заказчиками мы такие вот постановки, но на ЧТЗ на команду это не работало. Так например бэку нужно было больше инфы для воспроизводимости: стенд с фикс настройкой, предзаданные данные, отметка по ролевой модели (под кем должна была отрабатывать серверная логика) + спецификация по отработке ошибок + алгоритм расписанный на "пальцах" (рисовали в Миро или Excel). Фронтам же и ещё часто требуются ссылки на Ui kit, требовались пометки какой именно UI компонент юзать и с какими его настройками.
крч, такие постановки сильно человекозависимы. Способен их человек читать или понимать. Как ПМ первое что мы сделали с командой - это сделали соглашение кому и что надо видеть в постановке и договорились кто и как делает постановки да ЧТЗ. Из моего опыта - такие постановки как у автора - это для тимлидов, техлидов и QA пишутся аналитиком. А вот реальные задачи для трекера с декомпозицией - это уже лиды пишут из постановки на конкретно технарском языке (компоненты + ручки + состояния) и последовательность/зависимости нарезанных задач. Тогда можно играться в скрам и на стендапах это все отслеживать, чтоб не облажаться на тестировании да приемке задачи.
по сути разработчикам нужно видеть в постановке то, что нужно именно им для разработки. Отдельные пункты ЧТЗ и постановок от аналитики могут быть избыточными, или наоборот неполными. Прежде чем писать постановку стоит показать структуру типовой постановки конкретной команде и спросить все ли им хватает или не хватает по данному проекту. Обычно есть уточнения и пожелания.
Сюда еще накину такой смысл: в идеале постановки должны соответствовать зрелости команды и процессам компании. Отдельным людям достаточно просто направление, цель и задачи фичи дать - и они сами по красоте развернут все, быстро покажут на демо и доработают под конкретного заказчика. Другим достаточно ЧБ схематичного прототипа с типовым golden case (дальше они сами задолбают вопросами). Третьим же нужна чуть ли не пошаговая инструкция по шагам что, где и как надо изменить/добавить. Четвертым же сразу нужные ещё и тест-кейсы по которым будут написаны авто-тесты и под которые будут подгоняться реальные задачи на разработку.
Зарезюмирую: для старта написания постановок (если не знаешь как вообще) - крутой материал. Для практики - стоит учитывать реальных разрабов, заказчиков и команды.
Автору - мне бы было более ценно от вас услышать экзотические изменения в постановках, что требовались заказчикам или командам и зачем именно. Это если вдруг вы решитесь на ещё одну статью.
Дисклеймер: я хочу автору позадавать вопросы для более полной синхронизации с его месседжем. И, возможно. навести на новые мысли.
Автор, правильно ли я вас понял, что:
Вы делитесь своими субъективными переживаниями от собеседования кучи "специалистов" с неоправданно завышенными зарплатными ожиданиями? То бишь вам пригорело по итогу икс собеседований за период.
Вы старательно ищете на рынке кадры, которые вам будут идейно близки (задротство в терминах, а также четкое знание матчасти).
Правда мне не очень понятно как это поможет выполняемой функции системных аналитиков? А какая она основная функция системных аналитиков, кстати. Ну, по вашему мнению? Что является результатом работы аналитика? Без воды, желательно. Задача: описать результат работы аналитика в 2 предложениях.
Пояснение: я хочу понять каким образом четкое знание матчасти и терминов вяжется с ожиданиями результатов работы конкретного кадра. Например, если я ищу повара - меня интересуют какие блюда он умеет готовить и как быстро и качественно он это делает. А чтобы понять правду он говорит или нет - я дам ему задание приготовить одно из названных блюд. И оценю время, качество и вкус. А ещё посмотрю на подачу, состояние кухни после готовки и ошметки от ингредиентов. Надо ли при этом повару знать чем помидор отличается от свеклы и как их выращивают - вопрос. Это может быть точкой роста на перспективу по мере наработки статистики по продуктам.
Вы хотите немного почесать своё ЧСВ (своим опытом). Я тут без наезда. Это просто пирамида Маслоу - жажда признания (профессионализма).