Junior-Middle-Senior — какими попугаями меряем?

«We don’t need better solutions, we need better thinking about problems.» R. Ackoff

В мегатопике от Максима, который на момент написания заметки имел 400+ комментов :), в ходе обсуждения я привел такие вот критерии для Junior-Middle-Senior по уровню сложности работ и самостоятельности:

Jun: сам делает простую работу и под надзором — среднюю
Mid: сам делает среднюю работу и под надзором — сложную
Sen: сам делает любую работу и ещё может надзирать

работа делится на:
простая — неинтересна, понятно как делать
средняя — интересно, понятно, что можно сделать, но есть неясности с потенциальными неожиданностями — эдакий «перчик» детектед
сложная — безумно интересно, но непонятно как сделать

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

Перейдя в продуктовую разработку (в том числе и заказную), система ценностей и критериев, естественно, поменялась, поэтому я бы хотел более подробно раскрыть свою текущую позицию на этот счет.

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

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

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

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

Исходя из вышеперечисленного — да, «можно быть сеньором в 23 года», а можно и не быть в 50. И возраст дает тут просто размер набора подходов, практик, паттернов мышления и принятия решений. Решает не возраст, а зрелость. Причем не половая, а интеллектуальная :)

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

Поэтому, спор о «сеньорити» — ни о чем спор :)

У меня вот такие приоритеты, потому что я помогаю решать проблемы бизнеса за деньги и моя аудитория — зрелые не возрастом а мышлением люди, которые занимаются решением проблем средствами разработки и внедрения софта. И погон у таких людей только двое — разработчик и тестировщик :)
Я хочу делать «максимальное качество за приемлемую стоимость или приемлемое качество за минимальную стоимость» [c] и постоянно переживаю за свои и чужие риски, а у кого-то другие жизненные приоритеты и поэтому, естественно, он придумал себе другую градацию со своими возрастными планками, погонами и высотой стульев.
Все зависит.

С уважением и извините за болд в тексте — расставил акценты, чтобы не было кривотолков :)

Підписуйтеся на Telegram-канал редакції DOU, щоб не пропустити найважливіші статті.

👍НравитсяПонравилось0
В избранноеВ избранном0
Подписаться на автора
LinkedIn



Підписуйтесь: Soundcloud | Google Podcast | YouTube


112 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

полностью поддерживаю вышеизложенные в статье мысли


— человек умеет и хочет решать проблемы средствами ИТ.

— человек не всегда умеет, но хочет решать проблемы средствами ИТ.

Все, приглашаются в команду только такие люди. Остальные — нет. Под «проблемой» понимается комплекс проблем, которые надо решить и преодолеть, чтобы некую идею превратить в программный продукт и дать это продукт людям.

Ну мля, видно зразу «производственника» совковоi закалки.

У Вас там видно однi майстри та бригадiри.

При этом, невозможно полностью откреститься от части проблем (внедрения, например) и сделать только кусочек интересной для тебя работы.

Стиль роботи — бiгати всiх копати (в СофтСервi ознайомився з такою моделлю).

Поэтому, спор о «сеньорити» — ни о чем спор :)

Ну моя думка залишаеться такою: що джун — не знае як роботи, сенйор — знае як не тре робити.


Ну мля, видно зразу «производственника» совковоi закалки.
У Вас там видно однi майстри та бригадiри.

если бы вы ещё сами знали, о чем говорите — было бы чудесно :)

Стиль роботи — бiгати всiх копати (в СофтСервi ознайомився з такою моделлю).

как мило. модель, когда решается весь комплекс проблем по превращению идеи в продукт и внедрения этого продукта в живое использование — вы для себя интерпретировали так. глубина анализа налицо.

Ну моя думка залишаеться такою: що джун — не знае як роботи, сенйор — знае як не тре робити.

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

похоже, что и вам не помешало бы не просто читать написанное по диагонали, но иногда и обдумывать прочитанное.

1) Дядя, я починав ще працювати в СРСР, так що не надо гнать волну.
2) то не мило,
3) не надо ляля, в статтi нiчого чiтко не сказано, крiм одного

Поэтому, спор о «сеньорити» — ни о чем спор :)
Тим От як можна вIдрiзнити iнженера вiд ПМ/менеджера.
Перший дасть коротку, лаконiчну, зрозумiлу вiдповiдь, а другий довго товктиме воду в ступi нi про що.
4) Вам би не завадаило навчитись викладати думку зрозумiло та в становленому форматi (вiд загального до детального).
Стиль викладу такий:
а) теза
б) розвиток тези
в )висновок.
Саме тому такий стиль придуманий для бiглого читання «по дiагоналi».
Тобто дивишся початок, якщо цiкаво — далi в кiнець, якщо варте уваги, читаеш тодi тiло текста.
А обдумувати непродуманий набiр фраз — дурна трата часу. За чтиво у вIльний час потягне.

шо, ещё один «мерятель с 20-летним стажем», начавший учиться в ВУЗ-е в 1991-м и считающий, что он при этом «работал в СССР» и все знает «за совок»?

извините, но я вас баню.

Тут в PDF наткнулся на такое:

The “scope” category reflects how much responsibility you have. In larger companies it’s all about how many levels of managers you have under you.

At Stack Exchange, we don’t have strong ownership in areas of the code, and there aren’t a lot of “scope” levels, but we do have:

1. Newbie — not yet trusted to write code on their own, mostly given smaller tasks and working under close supervision. Tends to go no more than a couple of days at a time without needing more input from a manager. Expected to move up to “contributor” quickly.
2. Contributor — writes large chunks of code on their own. Tends to go a few weeks at a time without needing major direction from a manager.
3. Architect — designs major systems independently. Leads the design and development of large important pieces of code that take months to build. Proposes and advocates major new features and then drives them to completion. Leads several other developers, either as a manager or peer.
великолепный пример, спасибо за линк.

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

Похоже на то. Интересно, какое у Джоеля соотношение по количеству человек этих трех категорий и насколько quickly newbie стает сontributor-ом.

Там же чуть дальше еще и об опыте (больше актуально к обсуждению колонки Макса правда) есть:


Programmers tend to acquire skills at radically different rates. There are plenty of 18 year old programmers who can run circles around 20-year veterans. That said, there are bands of experience inside of which the market does tend to compensate differently. For example, companies our size almost always have a single, fixed starting salary for new CS graduates, regardless of skill (probably because they can’t really tell “skill” until the kid has been working for a while). After someone has been out of school for a year, skill matters much more in determining salary.

Our bands of experience are:
1. College student or intern
2. 0-1 years
3. 1-5 years
4. 5-15 years
5. 15 years+

We measure experience as full+time+software+development+experience.
• Time spent doing nonOprogramming jobs doesn’t count
• Time spent in college, in coops or internships, or before graduation (for someone who went to college) doesn’t count

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

не дословно, но в целом такая была концепция.

Вот только не понял немного. Это противоречит мнению изложенному в статье.
Или наоборот заменяет концепцию Jun/Mid/Sen и дополняет статью.
Я думаю что если второй вариант,то это правильно в какой то мере,все же должны быть какие то критерии помимо Разработчика или Тестера.

Думаю стоит делать относительные оценки между участниками проектов.

Поэтому, спор о «сеньорити» — ни о чем спор :)

Полностью согласен, так как это попытка как-то «обыграть» спрос-и-предложение. Есть спрос — цена растёт, нет — падает и не важно, кто это разработчики или кондиционеры.

Здесь вопрос не в продуктовости\аутсорсовости, а в количестве разработчиков в обозримом пространсте. Чем меньше разработчиков, тем можно более специализировать критерии. Чем их больше, тем ценнее формальные критерии, которые работают «хорошо в среднем» Принцип неопределённости Гейзенберга ещё никто не отменял.

Вот рац.предложение — давайте усилием ДОУ сообщества сформулируем такую градацию, базирующуюся на мировом опыте и украинских реалиях и разместим её здесь, вот это будет ценный артефакт.

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

я постил топик не с целью навязать точку зрения, а показать, что есть и другой взгляд — когда погоны семантически другие и их меньше :)

После вчерашней, вышеупомянутой темы, пообщался на форуме, и выделил для себя действительно истину

A — Кто то вменяемо понимает разницу между сеньйором и мидлом?
B — а в чом вопрос? кем быть? или недоплачивают за «звание»? :-)
A — Вопрос в том, кто я?
B — обычный наемный рабочий :-) еще остались вопросы? =)

я просто к тому — если работа устраивает, зарплата нравится — ****(зачем) какие лычки? работай и двигайся вперед, а эти крашеные *****(дураки) кто *****(вон из кожи вылазит) за лычки со следующим кризисом будут хлеб сосать и плакать что их все побросали потому что они *****(ничего) не стоят на самом деле, жизнь *****(плохая), украина ***** (плохая), президенты ******(очень плохие) и тп :-)

ну и по факту, тут ты сеньор, вдруг случится что пойдешь под нож, не факт что в другом месте будешь сеньор :-)

а в жизни как.. реализуй простые потребности на первом месте — пожрать да ******(заняться сексом) :-)

хватает на обе вещи — отлично, еще остается — еще лучше, можн она ******(сбор форума) ездить :-)

Всё же склонен придерживаться мнения этого человека, зачем они нужны эти звания?

P.S. Оставил оригинал, заменив *****, для пущего еффекта))))

ТС — вы хам и невежа , но это повидимому не мешает вам быть специалистом достойного приличной работы это так сказать обратная сторона медали которую вы сами себе выдали.
Единственное что хотелось сказать все ваши «членомерки» — сеньоры, мидлы, джуниоры лишь удачная манипуляция, причем в каждой конторе этот «членомер» растянут до размеров ведущего специалиста в конкретной конторе — это напоминает мне преподов с любой кафедры.
Они говорят — я знаю на 4 студент на 3 ,а на 5 знает только сам Бог!

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

это вы мне или кому-то из комменторов? не понял ничего :)

Пипец , сеньор это не гуру оказывается, а юникейщик о_0

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

не знаю, нужно ли объяснять, почему решение проблемы бизнеса более сложное, чем написание качественного кода?

Конечно, автор налил воды. Можно было бы написать только

Поэтому, спор о «сеньорити» — ни о чем спор :)

...

Рекомендую всем почитать Стива «Professional Software Development», немного не то направление, но ставит мозги на место и показывает реальные вещи... Я бы рад был, если бы писали топики на таком уровне, а эти все трехомудия о «помидорах» — детский сад...

кхм... простите, но я это читал. и то, что разработка софта — решение каскада проблем и поэтому градация разработчиков должна быть или привязана или опираться на умение/неумение/желание решать проблемы — это как раз «великий и могучий» McC выдал в середине 90-х :) так что с его точки зрения спорить есть о чем и у него цельные теории под это подведены по управлению рисками и обязательствам именно в такой профсреде, которую я описал.

я рад, что для вас ничего не было новым в статье, но посыл все-таки был не о споре о сеньерити :)

нет, просто приведенная вами книжка — многоплановая и вы могли этого не уловить. тут надо читать весь комплекс его книжек и статей, кроме разве что «Код», если интересна тема компетенций и отношений к работе

Во многих вопросах всем нам так или иначе приходится полагаться на чужое мнение. Особенно, в таких сложных как выбор сотрудника или делового партнера. Поэтому, различного рода атрибуты в виде званий/дипломов/рекомендаций/цветных штанов, всегда занимали прочное место среди критериев первичной оценки кандидатов. И от этого никуда не деться. По крайней мере, до изобретения миелофона :) С другой стороны, понятно, что одна лишь эмблема Adidas™ не гарантирует качества кроссовок, купленных с рук в переходе. Но ведь и отбор не ограничивается лишь взглядом на «погоны» и технологию, но учитывается и репутация компании, эти «погоны» присвоившей, и проект, в рамках которого получено повышение, и общий стаж, и образование, и много чего еще. Поэтому, спор о «сеньорити» в вакууме действительно ни о чем. И если в наш капиталистический век, вчерашний студент гордо зовется «сеньором» и зашибает $3К в месяц — значит — это кому-нибудь нужно.

и это не только мое мнение и наблюдение — профи не кичаться дипломами и лычками, они им нах не нужны. они гордятся своими достижениями в определенных предметных областях. для работодателя, которому не нужно просто закрыть вакансию ибо голов не хватает, а он ищет человека, которому мог бы доверять — гораздо важнее не:
«я в международной компании Х сделал за 3 года карьеру с ХХ до ХХХ и получил команду ХХХХ человек»
а

«проект Х, распределенная архитектура, ускорил межсерверное взаимодействие в ХХ раз, отодвинул порог масштабируемости на ХХХ, что удешевило реализацию бизнес-планов заказчика. делали это командой 3 дева + 2 тестера, справились за 3 месяца»

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

зы: я не против карьеростроения, я против перекосов в карьеростроении :)

Да дело не в том кичатся или нет, а в том, что в нормальных компаниях профессиональные достижения неотъемлемо влекут и карьерные. Зачем Вы противопоставляете, путая грешное с праведным? Ведь знаменитостей, фамилии которых слишком известны, чтобы их называть — единицы. И все они на виду. К Вам же, например, как к работодателю, приходит некий человек Х, о котором известно только из им же самим составленного резюме. И если оттуда следует, что он «в международной компании IBM сделал за 3 года карьеру с Intern’а до Senior Software Engineer и получил команду в 10 человек» (что сравнительно легко проверить), то на такого соискателя определенно стоит взглянуть, согласитесь. А фразы вроде «ускорил межсервисное взаимодействие в ХХ раз» совершенно ни о чем не говорят, напоминая скорее рекламу виагры. У Вас, ей-богу, какие-то юношеские максималистические представления о труде инженера.

И если оттуда следует, что он «в международной компании IBM сделал за 3 года карьеру с Intern’а до Senior Software Engineer и получил команду в 10 человек» (что сравнительно легко проверить), то на такого соискателя определенно стоит взглянуть, согласитесь.

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

недаром в CV есть такой раздел «Achievements», не так ли?

А фразы вроде «ускорил межсервисное взаимодействие в ХХ раз» совершенно ни о чем не говорят, напоминая скорее рекламу виагры

простите, но это явный повод для разговора, потому что в CV принято немного приукрашать :)

касательно «виагры» — ваша логика поражает. «я работал в компании ХХХ и стал тимлидом команды в 10 человек» — это нереальная конкретика, по-вашему, а «я умею делать то-то и то-то и доказал это на практике» — это фуфло?

нормальных компаниях профессиональные достижения неотъемлемо влекут и карьерные

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

налицо системное мышление и инженерная зрелость, мои аплодисменты :)

developer — это не только ценный.... это не только код, монитор и кресло. Совершенно ничего не сказано об умении общаться с заказчиками, с ВА, с QA, с РМ. Не хочется верить, что «украинский синьер» — это еще и тепличное растение, которое перекладывает всю «неинтересную» работу на TL/PM, а вместо 15 мин разговора с коллегой за океаном вкуривает мантры с хабры =)

Є альтернативний варіант оцінювання кваліфікації розробників, який я колись прочитав в книжці Едварда Йордона “Смертельный марш” (існує інша назва російського перекладу — “Путь камикадзе”). В оригіналі вона називається так: Edward Yourdon “Death March”, Prentice Hall, 1997, ISBN 0-13-748310-4. Я його вирішив привести не для того, щоб “підлити масла в вогонь” цієї дискусії, а просто щоб ви звернули увагу на те, що є і інша система коородинат, ніж звична всім джуніор-мідл-сеньор і подивились на кваліфікацію трохи під іншим кутом.

В замечательной статье [1] мой коллега Mellir Page-Jones утверждает, что в разработке ПО существует семь ступеней мастерства; его статья сосредоточена в основном на методологиях, но я думаю, что она в такой же степени применима к средствам и технологиям. К списку, приведенному ниже, я добавил свои собственные оценки, касающиеся времени достижения разработчиком средней квалификации различных ступеней мастерства в предположении, что средство или технология обладают средней сложностью.

Семь ступеней мастерства в разработке ПО

1. Наивный новичок: никогда не слышал о технологии Х (очевидно, для этого не требуется никакого времени).

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

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

4. Практикующий разработчик: готов использовать технологию Х в реальном проекте (по-видимому, достаточно месяца, чтобы в основном постичь все нюансы использования средства и быть вполне готовым к его использованию в “реальном” проекте).

5. Квалифицированный разработчик: постоянно использует технологию Х в своей работе и очень недоволен, если по какой-то причине лишается этой возможности (для достижения такого уровня обычно требуется 6-12 месяцев, и если средство действительно подобно “серебряной пуле”, то разработчик превращается в проповедника и пытается всеми способами убедить каждого, что это средство — самое замечательное в мире).

6. Мастер: усвоил все детали технологии Х; знает, как обходить ее правила (на это требуется два или три года, это также означает, что разработчик прошел через две или три новые реализации продукта, познакомился со всеми пользовательскими сообществами в Internet, знает все отсутствующие в справочниках номера телефонов специалистов по технической поддержке в организации поставщика).

7. Эксперт: пишет книги, выступает с докладами на конференциях, ищет способ распространить технологию Х на другие галактики (Page-Jones в своей статье говорит о методологиях, поэтому не совсем очевидно, что это применимо по отношению к средствам и технологии).

Литература к главе:

1. Mellir Page-Jones.The Seven Stages in Software Engineering. American Programmer, July-August 1990.

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

7 уже не генерирует прямую ценность, он — икона и распространяет :)

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

схема, когда рейтинг разработчика построен на флаге «можно доверить/нельзя доверить» и категориях сложности работы — имхо проще и удобнее. короче — чем меньше погон в разрезе контроля качества, тем эффективнее управление. собственно — одна из ценностей auftragstaktik, которую сейчас принято звать agile подходами :)

Меня вот одно удивляет, а почему никто не подумал что один и тот же человек может в одной задаче/проекте разбираться лучше из-за разных причин в другом хуже. В первом он по классификации выше будет сеньором, в втором мидлом скажем. Ну один человек может прекрасно понимать как написать бизнес решение для объемных и запутанных потоков данных но решение в котором надо что-то считать с учетом разных параметров он будет писать больше другого человека у которого ситуация противоположная. Да и они оба прекрасно владеют инструментами и знают что и как делается но у одного лучше это у второго вот это. Вроде мысль верно записал :)

почему не подумал? можно установить прозрачные отношения «заказчик — исполнитель» на любом уровне в зависимости от целей и пути достижения целей.

вот час назад буквально — я заказал ведущему разработчику проекта профилирование и оптимизацию сложных выборок данных финансовых транзакций в распределенной системе. ибо он лучше «сечет» в оптимизации запросов ибо практик давний в этом и лучше меня.

а я «секу» в экспертных оценках и тестировании лучше него и он мне заказал выработку методики и требований к окружению для тестов, чтобы иметь четкое понимание их синтетичности и определения пределов запаса прочности оптимизации выборок при увеличении нагрузки и объема данных, ибо принимать решение о сегментировании запросов или изменению модели данных и межсерверного взаимодействия возможно придется и под это нужно взвешенное обоснование :)

одна задача и мы выполняем обе роли каждый.

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

Ну когда два специалиста так сотрудничают это отлично

в рамках проекта это два специалиста, в рамках компании я рулю филиалом, а он — разработчик

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

честно — не понял :) смысл лычек и званий — их выставляют напоказ :) и какие лычки вы не хотите шарить — звание разработчик или тестировщик? или разработчик проекта «Х»? или разработчик, который умеет «Y»?

проясните, пожалуйста :)

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

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

1. И меня свое имхо на счет таких вещей но это не тема разговора.
2 и 3 Смысл в том что если ты SoftDev ты будешь им пока не сменишь направление а вот жуниор, мидл или сеньор зависит от проекта и твоего вклада в проект. Коробит когда человек один раз вел какое-то направление в проекте и возомнил что он мидл или там сеньор хотя в среднем за ним глаз да глаз нужен.

Так ясней ?:)

похоже, что мы с вами об одном и том же говорим на разных языках просто :)

2 и 3 Смысл в том что если ты SoftDev ты будешь им пока не сменишь направление а вот жуниор, мидл или сеньор зависит от проекта и твоего вклада в проект. Коробит когда человек один раз вел какое-то направление в проекте и возомнил что он мидл или там сеньор хотя в среднем за ним глаз да глаз нужен.

именно! я об этом и писал, что уровень сеньорити зависит от контекста решаемых проблем и желания и умения решать эти проблемы, а не от количества изученных фреймворков :)

которые занимаются решением проблем средствами разработки и внедрения софта

Я почему-то всегда думал что средствами внедрения софта проблемы решает в основном IT отдел/системные администраторы/называйте их как хотите (хотя это возможно зависит от размеров компании?)

не всегда. на сложном проекте этим занимается команда — админы, разработчики и тестировщики и у каждого свой спектр задач по автоматизации, развертыванию, тестированию, контролю целостности, восстанавливаемости и т.д. многие задачи, к тому же, разнесены по этапам жизненного цикла проекта.

Ну я как раз о том что админы забыты, а вот тестировщики уже которую статью впереди планеты ) погон на всех не хватает? )))

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

работа у них тоже связана с требованиями, анализом, проектированием, документированием, экспертизой и исполнением — весьма неиллюзорная бизнес-ценность. к тому же, тестировщики часто выступают внутренними заказчиками.


— человек умеет и хочет решать проблемы средствами ИТ.

— человек не всегда умеет, но хочет решать проблемы средствами ИТ.

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

А людей, которые умеют и хотят решать определенные проблемы определенным образом вы не рассматриваете? Например, «решать проблему создавания веб-приложения с помощью RoR» или «решать проблемы создания программных продуктов, но только не на коболе»?

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

к тому же, вы начали оперировать технологиями. это прямо «по фрейду» :) для бизнесмена — заказчика нет понятия языка программирования, есть понятие достигнутых целей в корреляции со стоимостью пути достижения целей. поэтом, «определенный образ» у нас с вами может быть разный, но на определенном абстрактном уровне 100% сойдется и окажется, что мы ни о чем спорили :)

Потому что вряд ли можно найти человека, который с одинаково горящими глазами будет верстать хтмл, устаканивать требования с заказчиком, писать код на джаве и разгребать чужой код 20-летней давности на ассемблере.

читайте то, что написано :) не нужно додумывать. тем более, что процесс решения проблем бизнеса однозначно подразумевает технико-экономическое обоснование и управление рисками. и если это так, то оутсорсинговая компания с грамотной моделью не возьмется за описанный вами проект — слишком велика вероятность пробоя по рискам и обязательствам со всеми вытекающими. а продуктовая компания — выпустит новую версию. приведенный пример не совсем нежизненнен и нерелевантен :) есть частные случаи на рынке, но они частные. и это явно не про то, что я писал. вы опять съехали в технологии :) или вы считаете, что у владельца бизнеса есть проблема поддержка кода на языке ХХ? чуть более чем сомневаюсь :)

и как дополнение — если человек решает проблему бизнеса прежде всего с помощью языка программирования, то 99,99999% у него плохо с абстрактным проектированием и манипулированием предметными областями проекта :) а вот реализация технического решения проблемы на конкретном языке программирования в терминах предметной области разработки в соответствии со спроектированным в терминах предметной области проекта дизайном — это общеиндустриальное «наше все» :)

Ок, выражусь яснее. Это бизнесменам интересны заказчики и их бизнес-проблемы. Программистам же интересны проблемы технические. (внимание: слова «только» в предыдущем предложении нет). То, что вы описали — это PM, но ему все равно нужны будут люди, которым интересны ТЕХНОЛОГИИ, а не заказчики. Потому что в конце-концов кому-то придется написать код, и хорошим он будет только тогда, когда его напишет хороший программист, читающий ночами доки и пишущий вечерами опенсорс.

хм... думается, что вашему работодателю и вам, если вы сами работодатель — не нужны программисты, не так ли? вам нужны разработчики :) т.е. программисты, но с уровнем компетенций +1 выше. каждый разработчик (даже самый распоследний джун) — ПМ на своем проекте. ибо задача от проекта отличается только масштабами, а так — все как всегда: кто-то что-то заказал для чего-то.

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

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

а как разработчик напишет «хороший» с т.з. заказчика код, если ему пофигу, как этот код будет применяться у заказчика? заказчик ему же неинтересен, ему «ТЕХНОЛОГИИ» подавай :)

и не хочу показаться нудным, но общепринятым термином написания кода является «кодирование», а «программирование» — более обширное понятие :) как и «разработка» в случае перевода с «development» — более широкое, чем программирование :)

зы: я не противник технологий, я — противник перекоса значимости этапа написания кода в пищевой цепочке «идея — деньги», с которой мы с вами кормимся :)

и не хочу показаться нудным, но общепринятым термином написания кода является «кодирование», а «программирование» — более обширное понятие :)

%) вот это бред...

вы читали трэд полностью или просто глаз зацепился за знакомые слова?

Да. А причём тут тред, если это вдруг оказывается «общепринятым термином»?

а притом, что терминология придумана до нас :) и если работу на уровне общего алгоритма работы приложения, в том числе и сегментацию его на более мелкие алгоритмы, назвали когда-то <b>программированием</b>, а реализацию абстрактного алгоритма на конкретном языке программирования в рамках <b>разработки</b> программы назвали <b>кодированием</b> — это не ко мне :) были разные таки дядьки в старинные 70-е, все претензии — к ним :)

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

имхо, вы не совсем к тому прицепились :) или я слишком задел вас «общепринятым термином», а ЧСВ не позволило уточнить степень общепринятости и агрессия пошла сразу?

зы: кста, я уже приводил примеры, что система ценностей agile была создана в 19-м веке, а scrum сформулировали в 40...50-е гг 20 в. и это исторический факт. что же нам теперь делать?

и если работу на уровне общего алгоритма работы приложения, в том числе и сегментацию его на более мелкие алгоритмы, назвали когда-то программированием, а реализацию абстрактного алгоритма на конкретном языке программирования в рамках разработки программы назвали кодированием — это не ко мне :)

Кто назвал?

проектирование/программирование, кодирование, тестирование, внедрение, верификацию, поддержку, рефакторинг,... ну, не мне вам рассказывать :)

Да нет, это что-то новенькое, по-этому, рассказывайте. Я наверное последние 20 лет был в катакомбах и многое пропустил.

имхо, вы не совсем к тому прицепились :) или я слишком задел вас «общепринятым термином», а ЧСВ не позволило уточнить степень общепринятости и агрессия пошла сразу?

Если честно, то это, скорей всего, реакция на словоблудие (ну и мегазавышенный ЧСВ, конечно же). Разницы между кодированием и программированием нет.

ну, мне все понятно :)

Я наверное последние 20 лет был в катакомбах и многое пропустил.

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

Кто назвал?

Вирт, Дейкстра, Брукс, МакКонелл и некоторые другие.

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

Около 10 лет назад эта была очень популярная тема для флейма на забугорных форумах. Это слова синонимы.

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

Программирование, не проектирование.

а формирование алгоритмов бизнес-логики, общих правил поведения, взаимодействия, реализации позитивных, негативных и исключительных сценариев без написания кода — это не программирование поведения будущего приложения? :)

как сказал один умный человек — если программируешь в коде, то гарантированно создаешь субъект рефакторинга, ибо генерирование решения на лету не есть вундебар. собсно, в том числе и под это дело всевозможные DSL-и и запилены :)

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

а формирование алгоритмов бизнес-логики, общих правил поведения, взаимодействия, реализации позитивных, негативных и исключительных сценариев без написания кода — это не программирование поведения будущего приложения? :)

Чем это не кодирование поведения будущего приложения?

как сказал один умный человек — если программируешь в коде, то гарантированно создаешь субъект рефакторинга, ибо генерирование решения на лету не есть вундебар. собсно, в том числе и под это дело всевозможные DSL-и и запилены :)

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

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

я безусловно понимаю, что вам, с 13 лет работающем в коммерческой разработке софта, наши слабые потуги познания мира и профессиональной сферы смешны и нелепы... ну вот и просветите нас тогда, пожалуйста — будем премного благодарны :)

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

You are welcome.

ну вот и просветите нас тогда, пожалуйста — будем премного благодарны :)

Разве не уже?

извините, но я не воспринимаю аргументы «мозг взорван, поэтому это неправильно».
я вам о разнице в цене ошибки и цене устранения рисков при разнородной деятельности, а вы мне только эго продолжаете тыкать.

спасибо, но взаимно неинтересно общаться, удачи :)

извините, но я не воспринимаю аргументы «мозг взорван, поэтому это неправильно».

У кого и что взорвано? :) Я говорил про фразу, с набором слов, соедиенными в предложение так, чтобы получился нулевой смысл.

Без обид, но Вы мне чем-то одного экстрасенса напоминаете, который вещал про вакуумные окошки в космосе, через которые он держит связь. «Программировать в коде», ставить в один синонимичный ряд «программирование» и «проектирование», и т.д. Что мы услышим дальше?

Через все ваши посты красной ниткой идет идея «Нужно Решать Проблемы Заказчика, А Не Тупо Писать Код». С этим я не спорю.

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

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

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

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

эээээ.... бизнес-цель пилота — не ваш дедушка :) его цель — из точки А в точку Б с заданными параметрами накладных расходов, амортизации, безопасности и много чего. ваш дедушка ему до фени. и если параметры в комплексе не достигаются — имел он вашего дедушку и будет кружить в коридоре ожидания. и цена ошибки пилота — понятна. цена ошибки разработчика — тоже понятно, но только не об землю, а об рынок.

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

ой-вээээй, ну сколько раз можно сегодня цитировать классика: читайте то, что написано :)

самоцитата...

— человек умеет и хочет решать проблемы средствами ИТ.
— человек не всегда умеет, но хочет решать проблемы средствами ИТ.

и как теперь вы смотрите на свою сентенцию?

бизнес-цель пилота

Именно. А цель программиста — код, который работает как сказано в спеке (устной, письменной — неважно), так быстро как сказано в спеке, и при этом читаемый и расширяемый. А не ублажать заказчика.

читайте то, что написано

— человек умеет и хочет решать проблемы средствами ИТ.

— человек не всегда умеет, но хочет решать проблемы средствами ИТ.

вы берете в команду только «людей, которые решают проблемы».

И? :)

Именно. А цель программиста — код, который работает как сказано в спеке (устной, письменной — неважно), так быстро как сказано в спеке, и при этом читаемый и расширяемый. А не ублажать заказчика.

вот опять 25... код — не цель как таковая. это одна из дочерних целей компании, в которой работает программист. на верху дерева целей — заработать деньги, а где-то в середине — написать коммерческий код. и заказчиком разработчика может быть ПМ, ТЛ, тестировщик, в конце концов. и без понимания целей компании в зарабатывании денег, хорошего кода не будет, нет?

и код хорошего качества за приемлимые деньги — это как раз «ублажить заказчика», не обманывайте себя, т.е. попасть в его ожидания. и ничего плохого в таком ублажении нет — повторные продажи, репутация и т.д. Если заказчик внутренний — профессиональное доверие со всеми вытекающими.

вы берете в команду только "людей, которые решают проблемы

именно так. а вы — нет? вы берете отчаянных пофигистов-забивателей на ваших клиентов и ваше желание заработать деньги?

а вторая строка самоцитаты говорит о том, что можно чего-то не уметь, главное — хотеть.

детальнее все написано выше, имхо :)

и без понимания целей компании в зарабатывании денег, хорошего кода не будет, нет?

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

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

и код хорошего качества за приемлимые деньги — это как раз «ублажить заказчика»

Это не «ублажить заказчика», это «хорошо выполнять свою работу». Установить связь между этими явлениями — задача бизнесмена.

вы берете отчаянных пофигистов-забивателей на ваших клиентов

На всякий случай: у меня нет компании, я техлид, и мне это нравится. :)

Но меня не коробит, если программисту не интересен клиент. Потому что — с чего бы, собственно?

а вторая строка самоцитаты говорит о том, что можно чего-то не уметь, главное — хотеть.

Я это учитываю.


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

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

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

Это не «ублажить заказчика», это «хорошо выполнять свою работу». Установить связь между этими явлениями — задача бизнесмена.

мне ли вам рассказывать, что в нашей области — области с резко выраженным фактором неопределенности, «хорошо выполненная работа» в комплексе, а не просто хороший код — весьма нечасты :) и такая работа вызывает «чувство глубокого морального удовлетворения» [c] у заказчика. это ли не «ублажить». касательно «задачи бизнесмена» — я вас прошу :) я видел на своем веку примеров up-sale в оутсорсинге, когда за это бралась команда и в комплексе результат был лучше, чем у менеджеров продаж и выше :) бизнесмен только овеществлял это в конкретные суммы, сам факт продажи был раньше.

На всякий случай: у меня нет компании, я техлид, и мне это нравится. :)

так и у меня нет компании — я наемный работник.

Но меня не коробит, если программисту не интересен клиент. Потому что — с чего бы, собственно?

особенно вас не коробит, когда вы выступаете заказчиком для своих подчиненных, да? так и представляю ваши ощущения: ему явно пофиг та задача и её окружение, что я поставил. но меня это не волнует, с чего бы, собственно? ну сделает фигню в режиме «отвяжитесь фашисты от партизана», ну переделаем пару раз — делов-то...

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

:-)

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

и такая работа вызывает «чувство глубокого морального удовлетворения» [c] у заказчика. это ли не «ублажить»

Это побочный эффект. Приятный, но побочный.

Дальше, насчет равшанов и джамшутов: эстетическая часть должна быть нарисована дизайнером. Глупо винить программиста, что у него нет вкуса, или что у него низкие требования к комфорту, равно как и глупо его винить, что он недостаточно силен, чтобы носить серверные стойки.

пилот аккуратен В ТОМ ЧИСЛЕ и потому, что боится потерять профессиональное доверие с вытекающими — это не доминирующий страх, рождающий ограничения в принятии решений и поведении, это — один из.

Это побочный эффект. Приятный, но побочный

этот «побочный» эффект совсем не косвенный — он прямо превращается в показатели оборачиваемости, инвестиционную привлекательность, ваши зарплаты, резервный, инвестиционный и прочие фонды и т.д.

Дальше, насчет равшанов и джамшутов: эстетическая часть должна быть нарисована дизайнером. Глупо винить программиста, что у него нет вкуса, или что у него низкие требования к комфорту, равно как и глупо его винить, что он недостаточно силен, чтобы носить серверные стойки.

вы или не поняли аллегорию, или решили пофлеймить :) замените плитку и эстетику

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

этот «побочный» эффект совсем не косвенный — он прямо превращается в показатели оборачиваемости, инвестиционную привлекательность, ваши зарплаты, резервный, инвестиционный и прочие фонды и т.д.

Какое дело программисту до показателей оборачиваемости и всяких фондов? Это заботы компании, и беспокоят они только тех, кому компания — не просто работодатель, а друг, товарищ и карьерная лестница.

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

В ТОМ ЧИСЛЕ и потому, что боится потерять профессиональное доверие

Давайте я тоже приведу аналогию. Если у вас есть ребенок, вы опасаетесь за его жизнь и здоровье потому что его любите, так? Можно ли сказать, что В ТОМ ЧИСЛЕ еще и потому, что если он умрет, то окружающие будут считать вас плохим отцом, да и с бумагами по инстанциям побегать придется?

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

Вы настойчиво игнорируете основной мотив профессионала. Он делает свою работу хорошо потому что это приносит ему удовольствие. И не делает плохо потому что ему просто противно создавать плохие приложения. Я пишу хороший, понятный код даже решая задачи с Euler Project — а этот код вообще никто кроме меня не увидит.

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

ИМХО, конечно.

Ну это от характера зависит. Есть люди, которым нравится хорошо делать свою конкретную работу и внешний мир их не интересует. Человеку хочется сделать хорошо свою формочку, он её любит и лелеет, а всякие бизнесс-процессы и юзеры его абсолютно не интересуют. И он от этого не становится хуже как разработчик, просто такому человеку задачи правильные ставить надо.

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

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

Ну если человек знает среду и средства разработки как свои пять пальцев, до мельчайших подробностей, все её возможности, пределы и слабые места, как ни один менеджер или архитектор не знает, может выполнить любую поставленную задачу оптимальным с технической точки зрения методом и в кратчайшие сроки, но при этом ему абсолютно безразличны всевозможные пользователи и бизнес-идеи — разве это не senior developer?
Да, это может быть и geek, ярчайший причём, но, по-моему, такими сильные девелоперы и бывают, немного не от мира сего. Людьми, которым не интересен бизнес, финансовые вопросы и прочая мишура, а интересен именно процесс разработки, как творение, как азарт, в этом их кайф.

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

не могу не согласиться, рациональное зерно в этом есть, но:

«...узкая специализация — это для муравьев...» [c] Хайнлайн :) :)

Цель любого провайдера услуг (в частности, девелопера) — помочь клиенту решить его задачу с заданным QoS и минимальными затратами. Клиент не должен мыслить спецификациями, его задача — сформулировать свою бизнес-задачу, а задача разработчика — предложить, как именно ее лучше реализовать.

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

QoS — это что?

Программист — провайдер услуг программирования для своей компании.

QoS = quality of service (имелось в виду качество решения, очевидно, что для авионики Боинга и игры для мобилки требования к качеству разные)

Программист — провайдер услуг программирования для своей компании

Это для продуктовой компании еще так-сяк применимо (хотя и там думать о пользователях не помешает), а в аутсорсинге — совсем нет. Какие-такие «услуги программирования» нужны Люксофту, ЕПАМ, Сиклуму и иже с ними? Они не продают программные решения, они продают команды, решающие задачи заказчика (какими бы они не были).

Они не продают программные решения, они продают команды, решающие задачи заказчика (какими бы они не были).

Они именно что перепродают услуги своих сотрудников — ПМов, программистов, тестировщиков.

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

Это только одна (самая простая) модель аутсорсинга — аутстаффинг (outstaffing). Есть еще, как минимум, managed services (продажа managed или self-managed команд) и managed delivery (разработка под заказ).

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

скажу больше — и в первом случае заказчиком выступает клиент компании и его задачи нужно решать :)

найти «правильных» людей в распределенную команду и минимизировать ряд рисков заказчика — это тоже нужно уметь :)

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

а я имел ввиду именно компанию :) она собирает команду для оутстаффера и должна сделать это хорошо

В случае нанимателя-аутстаффера — это не так.

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

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

+1, о том и речь.

вы забыли ещё про интеграцию и внедрение — всеобщий ass-pain и ass-hole :) и не только в нашей отрасли.

Юзабилити — это отдельная задача. Хорошо, если программист это умеет, но может и не уметь. Столяр не обязан продумывать, хватит ли вам места для телевизора в новом шкафу.

а технически юзабилити кто обеспечит?

Как программа должна работать, чтобы пользователю было удобно и красиво, придумают специалист по юзабилити и дизайнер. Например, «после свайпа список должен продолжать двигаться по инерции со скоростью свайпа, а потом линейно-логарифмически остановиться за 500мс».

В большинстве проектов, впрочем, такие решения оставляют на совесть программиста.

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

понятно, что потом приходит его величество end-user и все приходится переделывать, но сути это не меняет :) обратных связей больше, чем вы говорите — реализуемость и тестируемость «удобно и красиво» ещё никто не отменял :)

и вы правы — очень часто перечисленные роли — физически один человек, играющий в рулетку с субъективом своим и заказчика.

аналитик должен сначала сделать видимым процесс, который нужно реализовать и сформировать критерии к «удобно и красиво»,

Кто ж спорит.

мне показалось, что вы оставили только 2 роли из многих в этом процессе :) извините

для бизнесмена — заказчика нет понятия языка программирования, есть понятие достигнутых целей в корреляции со стоимостью пути достижения целе
Это не всегда так. Взять хотя бы опрос по языкам на этом сайте — в анкете есть вопрос «кто выбирает язык..» и заказчик там присутствует и это реально не только для аутсорсинга.
А в целом +1 :) Большинство Java вакансий, к примеру, содержат требования по знанию кучи фреймворков и разных страшных слов, а вот умение решать реальные проблемы (которое приходит исключительно с опытом) не упоминается ни в каком виде. Отчасти, отсюда и вытекает обсуждаемая проблема — линейка для определения проф. уровня и «сеньорности» — не та.

ну, по опросам и средние зарплаты 1,5к, но мы-то знаем, что это не так :)

Это не всегда так. Взять хотя бы опрос по языкам на этом сайте — в анкете есть вопрос «кто выбирает язык..» и заказчик там присутствует и это реально не только для аутсорсинга.

хм, а вам не приходило в голову, что это потому, что украинский оутсорс несколько перекошен в сторону оутстаффинга? и удельная плотность проголосовавших оттуда просто выше?

а вот умение решать реальные проблемы (которое приходит исключительно с опытом) не упоминается ни в каком виде. Отчасти, отсюда и вытекает обсуждаемая проблема — линейка для определения проф. уровня и «сеньорности» — не та.

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

нежелание превращать шишки в паттерны/решения порождает семантический провал в общепринятом термине «опытный разработчик/архитектор/тестировщик». а то, что такое нежелание/неумение есть и распространено — не нужно доказывать? ;)

зы: против оутстаффинга ничего не имею против — бизнес как бизнес, ничего плохого в нем нет :)

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

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

Отличные размышления. Особенно правильно сказано:

Решает не возраст, а зрелость. Причем не половая, а интеллектуальная :)

Да что ж если все так «просто», а на работу и младшим не устроишься ?

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

Если честно не понятно зачем назначать Sen. человека который ничего не пишет — какой же он тогда старший программист?

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

Да что ж если все так «просто», а на работу и младшим не устроишься ?

а где написано про «просто»?

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

заказчик

Если честно не понятно зачем назначать Sen. человека который ничего не пишет — какой же он тогда старший программист?

где написано, что Sen ничего не пишет?

В градации описанной ТС, есть один нюанс — любая сложная работа может быть разделена на очень мелкие и тривиальные задачи ... значит всю «сложную и ой как интересную работу» может сделать известное количество младших специалистов причем в гораздо меньшие сроки чем великий гуру

предпосылка неверна, 9 женщин за месяц ребенка не родят. к тому же, вы чуть более чем выкинули из цепочки своих рассуждений чуть более чем сложный процесс получения простых работ, т.е. упростили и выкинули весь процесс многоуровневого абстрактного и неабстрактного проектирования, сведя его к «любая сложная работа может быть разделена на очень мелкие и тривиальные задачи». лихо :)

единственное что требуется от младших специалистов это четко знать что надо сделать (по описанной выше градации они это знают)

предыдущая неверная предпосылка привела к неправильным выводам :)

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

о чем вы вообще? похоже, что у вас «что-то болит» и вы пытаетесь это натянуть на статью :)

все, что вы описали про костыли, к приведенной градации имеет очень опосредованное отношение :)

junior нуждается в супервайзинге почти всегда, middle нуждается в супервайзинге в исключительных случаях, senior способен супервайзить сам.
<140 символов, влазит в твиттер

а «простой работы» у нас практически нет. Большую часть из того, что мы делаем, могут подстерегать «ожиданные неожиданности»

а «простой работы» у нас практически нет. Большую часть из того, что мы делаем, могут подстерегать «ожиданные неожиданности»

в любом виде профессиональной деятельности «простая работа» по приведенным мной критериям сложности есть всегда и в больших объемах, не нужно лозунгов :)

и в вашей компании, в том числе, тоже заявляют, что одним из мерил профессионализма считается умение выполнять одинаково качественно и рутину, и арт-хаус :)


junior нуждается в супервайзинге почти всегда, middle нуждается в супервайзинге в исключительных случаях, senior способен супервайзить сам.
<140 символов, влазит в твиттер
влазит. и ещё больше не перекрывает массу нюансов, которые не перекрывает мой пост.

у вас слишком ещё более «общё» [c] получается. в чем ценность тогда? чтобы в твиттер влазило? :)

поздравляю, зачем вам колонка тогда? :)

«это дубли у нас простые» ©

Ага. И иногда понедельник и впрямь начинается в субботу, особенно перед релизом. Зато работать интересно :)

а если серьезно, то «простая работа» отличается конечностью оценок, предсказуемостью пути и результата, а риски превращены в задачи. у вас нет такой работы? не верю.

Jun — работает над задачами, нуждается в указании следующей задачи
Mid — работает над задачами, но сам их находит, и не нуждается в помощи

Sen — работает над проблемами, раздает задачи, у него всегда можно найти помощи

вопрос номер раз — это желаемое или действительное? ;)

и по пунктам:

Jun — работает над задачами, нуждается в указании следующей задачи

сомневаюсь, что помощь нужна только в целеуказании... а критерии приемки, а реализация, а приемка? и как быть с категориями сложности?

Mid — работает над задачами, но сам их находит, и не нуждается в помощи

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

Sen — работает над проблемами, раздает задачи, у него всегда можно найти помощи

не понял, в чем отличие? :)

Mid — работает над задачами, но сам их находит, и не нуждается в помощи

В аутсорсе это не работает 100%. За «сам находит» можно и по голове еще получить в придачу.

о том и речь была :)

в лихие 90-ые и начало 2000-х команда отвечала иногда карманом за «ненулевые накладные расходы с сомнительным выхлопом», прямо как в супермаркете смена :)

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

Если представить проект как mindmap, то:
— Jun — может работать лишь над самым мелким таском, и не факт что справится самостоятельно.
— Mid — может работать уже над узлом, при этом вполне осознано; он может узреть, что чего-то не хватает для завершения порученной задачи (т.е. находит таски, которые изначально не были заложены), и предпринять необходимые действия для достижения свой задачи
— Sen — строит mindmap

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

тоже есть такое подозрение, но пока эмпатии не возникло :)

— Jun — может работать лишь над самым мелким таском, и не факт что справится самостоятельно.

как бы то же самое, эмпатия детектед :)

— Mid — может работать уже над узлом, при этом вполне осознано; он может узреть, что чего-то не хватает для завершения порученной задачи (т.е. находит таски, которые изначально не были заложены), и предпринять необходимые действия для достижения свой задачи

это — да, но зона ответственности искусственно чуток сужена. эмпатия почти детектед :)

— Sen — строит mindmap

а вот тут — эмпатия пока нихт :) если я правильно понял, имелся ввиду roadmap. и что конкретно имелось ввиду под этим?

спор о «сеньорити» — ни о чем спор :)

Совершенно точно.

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