Про роботу · 27 січня 2012, 10:47 1015

Alexander Kuznyak, Delivery Manager Consultant в сам себе режиссёр

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

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | 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 интерна (для «монотонной» работы).

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

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

Теми: junior, middle, QA, senior, бізнес

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

Bogdan Verbenets .NET 03.02.2012 19:34

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

Відповісти

Підтримати

Igor S Full Stack Engineer 31.01.2012 00:20

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

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 31.01.2012 10:27

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

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

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

Відповісти

Підтримати

Igor S Full Stack Engineer 31.01.2012 11:49

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

Відповісти

Підтримати

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 31.01.2012 11:55

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

Відповісти

Підтримати

Eugene Russkikh Ruby dev в olololo services 30.01.2012 19:15

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

Відповісти

Підтримати

Vladimir Prokopchuk Team Lead в IBM 30.01.2012 14:20

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

Відповісти

Підтримати

Bogdan Verbenets .NET 03.02.2012 22:57

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

Відповісти

Підтримати

Vladimir Prokopchuk

Beaver Green 30.01.2012 13:06

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 30.01.2012 13:40

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

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

Відповісти

Підтримати

Ostap Vyshnya 30.01.2012 00:04

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

Відповісти

Підтримати

Anton Gorlin Senior .Net Developer в WiseTech Global 28.01.2012 21:23

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

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

Відповісти

Підтримати

Petro Sasnyk Solutions Architect в Hivecell 28.01.2012 01:44

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

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

Відповісти

Підтримати

Max Ischenko Founder в DOU.ua 27.01.2012 23:12

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 23:26

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

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

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

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

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

Відповісти

Підтримати

Max Ischenko Founder в DOU.ua 28.01.2012 10:29

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

Відповісти

Підтримати

Alexander Kuznyak

Max Ischenko Founder в DOU.ua 28.01.2012 10:32

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

Відповісти

Підтримати

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 28.01.2012 11:12

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

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

Відповісти

Підтримати

Max Ischenko Founder в DOU.ua 28.01.2012 20:59

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

Відповісти

Підтримати

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 29.01.2012 23:29

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

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

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 29.01.2012 23:41

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

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

Відповісти

Підтримати

Alexander Kuznyak

Ostap Vyshnya 29.01.2012 23:54

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

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 30.01.2012 09:33

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

Відповісти

Підтримати

anonymous 29.01.2012 00:06

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

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

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

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

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

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

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

Відповісти

Підтримати

Alexander Kuznyak

Vladimir Prokopchuk Team Lead в IBM 27.01.2012 17:08

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

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

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

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 17:20

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

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

Відповісти

Підтримати

Vladimir Prokopchuk

Vladimir Prokopchuk Team Lead в IBM 27.01.2012 18:21

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

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

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

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

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

Відповісти

Підтримати

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 22:47

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

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

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

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

Відповісти

Підтримати

Vladimir Prokopchuk

anonymous 27.01.2012 15:07

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

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

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

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 15:16

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

Вот и всё.

Відповісти

Підтримати

Sergey Svechnikov Frontend Web Developer 27.01.2012 13:20

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

Відповісти

Підтримати

Yaroslav Fedevych карлсон, который живет в подвале 27.01.2012 14:56

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

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

Відповісти

Підтримати

Sergey Svechnikov

Sergey Svechnikov Frontend Web Developer 27.01.2012 15:32

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

Відповісти

Підтримати

Yaroslav Fedevych

Michael P Software Developer в Xenoss 27.01.2012 16:31

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

Відповісти

Підтримати

Sergey Svechnikov

Alex 27.01.2012 12:18

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 13:38

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

Відповісти

Підтримати

Alex

Oleksii Mukha .NET Team Lead в Ciklum 27.01.2012 12:00

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

Відповісти

Підтримати

Нестор Иванович 27.01.2012 11:27

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

Відповісти

Підтримати

anonymous 27.01.2012 15:14

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

Відповісти

Підтримати

Нестор Иванович

Pavlo Voznenko CTO в ProSiebenSat.1 Digital 27.01.2012 11:26

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 11:42

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

Відповісти

Підтримати

Sergey Bushnyak CTO в Kelecorix 27.01.2012 11:48

1 senior — 2.2 birdy
1 middle — 1.4 birdy

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

Відповісти

Підтримати

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 11:54

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

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

Відповісти

Підтримати

Sergey Bushnyak

Sergey Bushnyak CTO в Kelecorix 27.01.2012 12:01

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

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

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

Відповісти

Підтримати

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 12:27

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

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

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

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

Відповісти

Підтримати

Sergey Bushnyak

proger 27.01.2012 12:32

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

Відповісти

Підтримати

Alexander Kuznyak

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 12:40

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

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 27.01.2012 11:11

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

Відповісти

Підтримати

proger 27.01.2012 11:05

2

Відповісти

Підтримати

Vadym Baranenko Solution Architect в EPAM 27.01.2012 11:00

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

Відповісти

Підтримати

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

Ваша пошта

Не підписуватись