Разумное использование средств на человеко-ресурсы?

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Предупреждаю, что «тайтлы»: синиор, мидл, джуниор — по украинским взглядам.

Предположим есть определенной бюджет: Скажем 5 попугаев.
Есть гипотетический проект 7-бальной сложности по 10-бальной шкале. Проект Web (Software as Service type), на .Net. И, скажем, до момента как надо приступить к работе (и на набор developer-ов или QA-ев, не суть) есть 2 месяца.

Есть варианты как его «сделать», взять:
1. 2 синиора, например по 2.5 попугая каждый...
2. 1 синиора, 1 мидла и 1 джуниора.
3. 2 мидла и 2 джуниора.
4. 1 синиора и 3 джуниора.
5. 1 синиора, 1 мидла и 2 интерна (для «монотонной» работы).

Может еще какие-то...
Варианты ± конечно из-за маржи ЗП, скиллов и прочего.
Я лично склоняюсь к вариантам отмеченных болдом.

Как вы думаете, какой вариант будет наиболее приемлемым чтобы сделать проект с максимальным качеством и в четко установленный срок?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

1 сеньйора и остальных интерн-мидлов ему в подчинение :) . 2 сеньйора могут начать спорить про то как писать приложение, а если есть чёткая иерархия, то нужно делать как старший велит!

1 ведущий и 3 аргументированных джуниора
такая команда накодит больше чем все остальные

но главное что бы джуниоры были заинтересованы.

Интересный вариант.

Задача «больше» накодить не стоит, физических строк надо как можно меньше, что, думаю, вполне логично и понятно всем.

Разъясните немного момент с агрументированными джуниорами. Что вложено в это понятие?

ну я и не имел ввиду физическое количество строк.
но в любом случае проект состоит на 80% из скажем так — обычного кода,
и возможно около 20% чего-то довольно умного. + работа по проектирования — вот для этого 1 синьор, а ему в помощь 3 джуниора, которые осознают, что им ещё учиться и учиться и очень этого хотят и очень хотят сделать проект и сделать его хорошо + например, какие-либо условия роста в компании, ну или , возможно, для кого-то будет аргументом ЗП.
вообщем имею в виду что джуниоры очень хотят учиться работать и расти профессионально.

Понял Вас, спасибо!

Берите по распределению Гаусса.

Я вот еще подумал, и теперь совсем уверен, что джуниоры не подходят. Если проект короткий (до полугода, скажем) то подтянуть джуна до уровня, когда он даёт хорошую отдачу, банально не хватит времени. Если же проект более долгосрочный, то у джуниоров есть одна интересная особенность: с получением опыта, навыков и ростом скиллзов у них очень быстро начинают размножаться попугаи...

Что за попугаи? Метафорами глаголите!

Информации для принятия решения маловато. Проект «с нуля» или переделка? Какой объем проекта (месяцы, годы)? Какой процесс (Agile, водопад, что-то строго формальное)? Какие технологии (самые новые, «вчерашние», «еще не решили»)? Какой уровень качества («для кардиостимулятора» или «интернет-магазин»)? Предметная область (нужна математика, алгоритмы, медицинские протоколы)?

Информации более чем достаточно для того чтобы решить именно поставленную задачу, точнее — говорить о реализации предложенных вариантов и о выборе наиболее реальных и верных.

Если Вы считаете иначе, ну что ж, значит Вы мне не поможете.

ваши вычислений — это пример «логики» ПМа, которая к логике реальной жизни отношения не имеет. Вы команды измерили в терминах бюджета — зарплатах испольнителей. Но делать проект будут рельные люди. И нет никаких гарантий что команды из вашего списка имея одинаковую стоимостью, продемонстрируют одинаковую производительность труда и одинаковое качество(если его мерять временем на исправление багов). И это даже если не обращать внимание, на факт, что производительность труда у разных програмистов с одни тайтлом может различатся в разы.

на 7/10 без синьора не обойтись.
т.е. сразу остается 1 синьор + 2.5 попугая.
дальше по проекту.
если есть сложные не связанные между собой задачи, то второго синьора.

если дело может обойтись одним «архитектором», то мидла и джуниора.

Як на мене в гіпототетчному випадку задача не має однозначно виграшного рішення.
А для конкретних людей можна вже думати. Якщо людей набираєте внутрішніх з «історією» відносин, то можна й на джуніках виїхати + сіньйор, якщо хочете вхопити з ринку всіх людей то взагалі ризиковано в будь-якому варіанті, тому що сіньйор може бути і не сіньйором(хоча на співбесіді таки кваліфікацію ще так-сяк можна вияснити), а от характер, роботу в команді, виконавчу дисципліну, відсутність тараканів в голові ви не виясните після хоча б одного закінченого проекту.

Тому мій висновок: для зовнішніх кандидатів нема «срібної кулі» і ризики сісти в калюжу високі в будь-якому випадку. Для внутрішніх кандидатів максимальну якість і чітко в термін мали б дати таки 2 сіньйора згідно математики, але життя річ нечітка і не завжди логічна і сінйьори можуть почати виясняти хто з них сіньйорістиший, чи хто з них крутіший архітектор і це навряд чи піде на плюс проекту. Тому я тут би розглядав є конкретний розробник Василь, є Іван, який їх бойовий шлях, скільки за їхній трудовий шлях ПМів спилось, скільки перевелися на спокійнішу роботу в садівники:). Бажано щоб їхні шляхи перетинались і вони працювали вже разом. В мене був випадок коли люди на іншому проекті помінялися ролями розробник, лід, той що став розробником сприйняв це дуже болісно.

Клево у вас там в Сиклуме, я смотрю. Гипотетический проект можно застаффить минимум пятью разными способами!

Макс, ну не уподобляйся ты троллям что переводят стрелки на Ciklum!

Это абсолютно мой спортивный интерес и надуманная ситуация, Ciklum никакого отношения не имеет к поднятому мной тут вопросу!

Да и ответ на него я давно для себя вывел уже и мне интересно что думают и как мыслят другие, — да бы вынести что-то полезное... а вы все в одну степь...

Единственное что удивило — что никто не взял во внимание тот факт что за 2 месяца (читай за месяц реальных поисков, а то и меньше, учитывая процедуры собеседований, возможный оффер, «подумать», «отказ», время перед выходом и так далее) можно банально не найти 2-х Синиор инженеров (того или иного вида) которые бы удовлетворяли требованиям, а может — даж и одного! :)

Как и то что мы решаем задачу в реальных, а не идеальных условиях!

Ты не понимаешь, я бейджик хочу!

А если серьезно, вопрос же несерьезный. :) Я бы начал с поиска сеньйора или мидла и уже с ним бы решал как дальше быть.

Вопрос как раз серьезный ;)

Макс, у тебя на все 2 месяца, думаешь, найдешь? — Сколько Арман искал себе людей помнишь?

Именно. Какой смысл обсуждать 7 сценариев, как будто у вас этих разработчиков как видов колбасы в маркете. Надо смотреть кто есть и как из этого собрать команду.

Макс, внимательно читай вопрос.
НИКОГО_НЕТ, надо искать и дан срок.
По этому и есть смысл!

Решить задачу надо учитывая все факторы, а не выдавать решения учитывая только один из них, как многие тут, да и вот ты сейчас тоже ;)

Жаль, что A/B-тестирования не получится сделать.

А вообще я за пункт 1.

Я бы начал с поиска сеньйора или мидла

это циклум, такой проект они начнут с поиска фрилансеров в по-дальше от Киева.

<sarkazm> И тебе спасибо что понял суть вопроса! :D </sarkazm>

> Единственное что удивило — что никто не взял во внимание тот факт...

Я, например, думаю, что Вы и сами знаете ситуацию на рынке, лучше меня, и мониторите этот вопрос совместно с HR.

IMHO: Конечно, можно написать такие требования, что найти кого-то будет сложно, это часто встречалось раньше, думаю и сейчас не редкость. Влепить туда продвинутый English (а бывают специалисты! и без разговорного English), просеять кандидатов тестами, даже не общаясь, а особенно, если написать волшебное слово «синьор», то отсеете много народа... И среди студентов бывают легкие на подъем, готовые к риску и обучению старательные ребята и девчонки.

С другой стороны, чтобы нанимать специалиста, если используются какие-то специфические(!) технологии/требования, то нужно хорошо понимать о чем идет речь, быть способным лично взяться за проект, поддержать проект, или же иметь друга, с соотв. опытом, который бы подстраховал в этом вопросе, потому как на собеседовании можно друг друга элементарно не понять или неправильно оценить сложность задачи, как в одну, так и в другую сторону.

Что интересно, я не замечал, чтобы на нашем рынке была распространена услуга консультирования в подобных случаях. А ведь многим разработчикам нужен лишь консультант или очень небольшая поддержка/технический супервайзинг, чтобы реализовать даже очень сложный проект.

Однажды, у нас искали ведущего специалиста по EJB, это было критически для проекта, очень маленькие сроки для релиза ... а наняли специалиста по Java Beans (да и бюджет для найма был ограничен), ошиблись, несмотря на то, что это абсолютно разные технологии и EJB во много раз сложнее ... в результате, конечно сыграли и другие серьезные факторы, — жесткий срыв сроков.

А что делать, если бюджет маленький или проект ненадежный, а специалиста все нет ... да и своих специалистов не проапгрейдили заранее или не подготовили к смене проекта ..., что делать, что заказчику сказать? Понятно, что нужно сказать как есть, а заказчик уже решит, что делать дальше.

А чего всех не устраивает первый вариант?
7/10 — достаточно сложный проект. Если брать статистику «успешности» проектов, то это явный претендент на невыполнение бюджета.
Тем более, если

с максимальным качеством и в четко установленный срок

то зачем вообще джуниоры, кофе заваривать и газеты приносить?

Или у нас термин «синьор специалист» стал настолько пошлым, что им работу поручают уже только под присмотром мидлов? :)

Например: 2 сениора могут иметь разные взгляды... + 2 человека это на 50% меньше человеко-часов чем 3...

Аргументируйте пожалуйста!

Ну, ок.
Senior Developer — старший разработчик (именно «старший», а не ведущий). Это сотрудник, в идеале, обладающий достаточным опытом и способный самостоятельно решать с максимальной скоростью и качеством любые задачи по разработке. При необходимости, способен выполнять определенные функции архитектора, но это не является основной задачей. Главное — чётко понимать поставленные технические задачи и методы их решения, а также, при необходимости, уметь задать правильные вопросы по дизайну. Аналогично для тестировщиков и т.д.
Само определение «синьора» — это что-то вроде вышесказанного, правда же?

Итого, есть достаточно сложный проект (7/10) с достаточно жесткими временными и качественными требованиям, которые нельзя нарушать. Судя по всему, для привлечения архитектора нам не хватает ресурсов.
Пункт 1. В этом случае, мне видится оптимальным отдать проект двум опытным специалистам, которые смогут адекватно разделить объем работы между собою и выполнять его при минимальном контроле. Плюс, если возможно, для решения различных текущих вопрос привлекать на короткие промежутки времени различные дополнительные ресурсы, будь то архитекторы или аналитики.
Пункт 2. Имеем мидла, которому необходима четко поставленная задача и контроль за её выполнением, и джуниора, который вообще загадка, как по способностям, так и по отношению к работе. Плюс синьор, который должен ставить задачи мидлу и контролировать их выполнение, вытирать попу за джуниором, при этом заниматься более-менее равномерным распределение работы в рамках команды да еще и как-то успевать выполнять свои непосредственные обязанности. Плюс в конце из этого всего надо будет как-то слепить один цельный продукт.
А синьор девелопер — это не лид девелопер, ему может и не нравится быть ментором для кого-то, ставить и контролировать задачи, — всё-таки это не основная сфера его ответственности. В этом случае действительно велик риск, что он потянет всё на себя и попытается вытащить проект на своих способностях, скорее всего безуспешно.
Пункт 3. Ну тут вообще нечего обсуждать. Кода в результате будет много, конечно, но результат мало кого порадует. Джуниоров надо постоянно контролировать, даже чтобы давать им простые задания — их кто-то должен выделять из общего объёма работ. Это ложится на мидлов, которых и самих по-хорошему надо контролировать, особенно в плане соответствия того что они делают требуемой функциональности. Плюс, мидлы не обязаны вообще уметь распределять задачи между ресурсами — это никак не их работа.

Остальные пункты — неинтересно. Особенно 4 — «квочка и цыплята» :)

Я бы вообще на проекты 7/10 с жесткими бюджетными рамками и ограниченными ресурсами не привлекал никаких джуниоров — им там делать нечего, имхо.

Все размышления исходят из того идеального случая, когда у нас заранее есть четкие и понятные технические требования к проекту. Иначе тут без архитекторов-аналитиков-пмов делать нечего.
Ну и, конечно, если приведенные варианты подразумевают наличие опытного технического супервизора, который и будет контролировать работу названной команды, — то это совсем другой разговор. Тогда варианты 2 и 3 уже можно рассматривать.

Большое спасибо, очень информативно!

А если все таки

если приведенные варианты подразумевают наличие опытного технического супервизора

... подробнее не выскажитесь при таких условиях?

IMHO: Тайтлы у нас ни о чем не говорят. Описан проект в очень общих чертах, недостаточно для принятия решения.

В зависимости от деталей, можно взять 1 толкового middle или senior и все,
чтобы только чел. был надежный и последовательный (это самое сложное), и не задвинул все «внезапно». Для подстраховки, на случай болезни и т. п., еще 1-го, вспомогательного (примерно такого же уровня), если позволяет бюджет. Но если есть 1 чел, уже можно что-то делать и много.

На этапе, когда будет что-то готово, или чуть раньше, можно взять хотя бы 1-го —2-х хороших тестеров, чтобы смогли помочь ловить баги, пока продолжается разработка. Для поддержки процесса тестирования, возможно будет нужен еще 1 разработчик, можно джуниор, чтобы делал интерфейсы к внутренним API сервиса и т.п.
Если есть web interface, то нужен дополнительный разработчик, т.к. уметь делать качественно и внутреннюю логику и интерфейсы одному чел. сложно.

Если нужно очень четко подобрать срок выполнения задачи с самого начала, то все намного сложнее, на мой взгляд, т.к. не всякий middle разработчик сможет это рассчитать вначале, я, например, не могу. А ведь речь идет о проекте который делается с нуля...

Я видимо как-то не корректно описал задачу...
Речь идет об одной команде: Dev или QA, или Design, или любой другой (а не о всех коммандах вместе), и о распределении бюджета при найме сотрудников в зависимости от их квалификации и абстрактной сложности проекта (читай поставленных задачь) — «7 из 10», учитывая что проект по сути «сайт» что предлагает какое-то сервисное решение, и что на найм есть всего 2 месяца (т.е. учитывать «доступность» на рынке тоже надо).

Вот и всё.

2-й, по причинам, описанным ниже. Но не 5-й, т.к. будет уходить слишком много времени на объяснение интернам что именно от них требуется. Закончится просто тем, что мидл или синьйор (или оба вместе) в один прекрасный момент просто плюнут, и решат, что проще сделать самим или написать скрипт, заменяющий двух интернов, что опять же, съест время.

написать скрипт, заменяющий двух интернов, что опять же, съест время.

Зате скрипт після того, як його напишуть, їсти не проситиме.

Тут полностью согласен, но по условиям задачи — время очень ограничено и терять его на обучение (особенно, бесполезного) смысла нету. Другими словами, во 2-м варианте, такой скрипт самого начала будет заложен в сроки проекта.

Такие скрипты можно потом на лучшую зарплату переманить в другие конторы ;)

на QA попугаи отдельно?

Не важно кто, QA или Developer, или даже Дизайнер Team — суть вопроса от этого не меняется никак :)

2 вариант, т.к. однозначно нужен минимум 1 опытный специалист, а мидл и джун могут повысить свою квалификацию уже по ходу проекта и именно по используемым технологиям. Этот вариант лучше 4-го, поскольку сениору проще что-то объяснить мидлу, а объяснять все 3-м джуниорам выйдет затратно по времени :)

2. нужен хотя бы 1 человек с ревалентным и заметным опытом — что бы избежать массового велостроения

Можно не нанимать такого чел., т.к. очень дорого да и не факт что пойдет на такой проект ... а просто заказать консультации как в самом начале проекта так и по ходу.

Странно что не было варианта: один синьйор и два мидла. Синьйор как архитектор предпологается. А два мидла на много эфективней и качественней могут делать проект, чем куча джуниоров и интернов. А Синьор может даже на парт тайм, для код ревью, ну и смотреть в ту ли степь идет проект, что б сильно не говнокодили.

Так как тайтлы «наши», то 1 сеньер и 2 мидла выходят за рамки «5 попугаев». По этому такого варианта нет, в противном случае выбор бы более чем очевиден! ;)

1 senior — 2.2 birdy
1 middle — 1.4 birdy

2.2+(1.4*2) = 2.2+2.8 = 5 должно хватить....

Вы подгоняете цифры. По «задуманной» схеме так не получается:
Сениор 2.5 попугая (описано вначале), мидл — 1.7 попугая примерно.

В сумме будет почти 6 попугаев, а у нас максимум 5.

В том, то и дело, что миддл не описан был=)

Переведите команду в регионы, уложитесь в 5, или найдите за те цифры, что я привел. Вопрос в том, чтобы выбрать наименьшее из зол или способ реализовать эффективную схему работы?

«Лучшая команда, это команда которой нет, но ее функции выполняются» =)

Я же выше написал что варианта «1 сениор и 2 мидла» нет специально (понимая под этим что он не возможен), иначе выбор бы в пользу этого варианта был бы просто очевиден.

Также вариант:

1 синиора, 1 мидла и 1 джуниора.

Очень прозрачно намекает что нет варианта «1 синиор и 2 мидла» :)

/offtop mode on
хє
циклюм решил вынести корпоративные обсуждения на паблик
/offtop mode off

Я не зря болд-италиком выделил слово «гипотетически» в теме.

Эта ситуация придумана мной из головы и к Ciklum-у не имеет никакого отношения :)

Если не сложно, предлагая вариант, — давайте аргументацию пожалуйста.

Підписатись на коментарі