пятница, 10 декабря 2010 г.

[work.prog] А где (и кому) нужны мастера на все руки?

Время от времени задумываюсь о том, где и как мне больше всего нравится работать. При этом пытаясь более-менее объективно оценить самого себя.

Я никогда не был супер-программистом, всегда видел рядом с собой тех, кто больше меня знал, кто лучше придумывал алгоритмы, кто лучше проектировал, кто писал более простые и понятные программы, кто выдавал более интересные и новые идеи… В общем, никогда я не был лучшим в какой-то одной области. Но вот чем мне удавалось брать (на что я сильно надеюсь), так это более-менее удачным сочетанием собственных посредственностей в разных направлениях.

Этому способствовали, похоже, и условия, в которых происходило мое профессиональное становление. В КБСП, куда я попал еще студентом, наш маленький отдел был, по сути, мелким стартапом, пытающимся создать свой собственный продукт – объектную SCADA-систему. И каждый программист в таких условиях был и швец, и жнец, и на дуде игрец. Приходилось и код клепать, и тесты к нему, и GUI-интерфейс строить, и, что вообще многие программисты не любят, документацию писать, причем самую разную документацию. С заказчиками, правда, не сильно общался, да и внедрениями занимался эпизодически, но все-таки что-то из этого и мне перепало.

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

Но Остапа что-то понесло :) Так вот, после нескольких страниц отвлеченных рассуждений, пора переходить к сути.

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

Т.е., если кто-то в большой программерской конторе является обычным программистом, то ему вряд ли нужны навыки архитектора, как и способность написать 100 страниц внятной документации. Или, скажем, архитектору более пригодятся знания в области buzzword-ов вроде SOA и ebXML (попытайтесь произнести это вслух на людях не смущаясь), чем практические навыки организации тестовых стендов и, уж тем более, опыт общения с техподдержкой заказчика.

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

Итак, где может быть востребован программист-многостаночник?

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

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

В-третих… А вот в-третьих уже и нет. Первые два пункта – это все, что приходит мне в голову. Только две потенциальные ниши. Не густо :(

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

Например, как на счет R&D подразделений в крупных компаниях? Может у кого-то есть опыт или ссылки на рассказы о таком опыте?

15 комментариев:

  1. Это очень интересная тема требующая комментариев. У меня они пока не созрели, но молчание разрушено.

    ОтветитьУдалить
  2. кхм

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

    не?

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

    ОтветитьУдалить
  4. @имя:

    мысль понятно, но как называется должность такого "оценщика" (вспоминается начало перестройки и понятие "госприемка")?

    ОтветитьУдалить
  5. или работа на себя, или какая-нибудь маленькая контора.
    но то что ты "многостоночник" не мешает быть профессионалом в какой-то области.

    ОтветитьУдалить
  6. >но то что ты "многостоночник" не мешает быть профессионалом в какой-то области.

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

    ОтветитьУдалить
  7. ЕО>Ты сейчас о том, чтобы быть хорошим спецом в конкретной предметной области? Вроде глубоких познаний в криптографии или алгоритмах сжатия мультимедийных данных?

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

    ОтветитьУдалить
  8. @night beast:

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

    ОтветитьУдалить
  9. ЕО>Боюсь, что у нас нормально себя чувствовать могут только специалисты по бухгалтерии и 1C. Уж они точно без работы не останутся.

    суровая правда жизни :(

    ОтветитьУдалить
  10. Таких мест больше нет... Не существует таких мест... Intervale - единственное место на Земле, где можно достойно работать специалистам широкого профиля... Intervale - великая компания...

    ОтветитьУдалить
  11. @Lamer:

    Великим компаниям нужны великие люди. Посему задумываюсь о том, куда податься, если моего величия (не смотря на всю его величину) перестанет хватать :)

    ОтветитьУдалить
  12. > но как называется должность такого "оценщика"

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

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

    при этом на неоцениваемые части можно отдавать фиксированный процент времени, и иметь полное право отрапортовать "неуспеваем" (например, емнип на 3-е твое возражение насчет кодирования)

    З.Ы. и при этом Lamer считает, что мой взгляд -- это взгляд с "противоложной" стороны, хе-хе

    ОтветитьУдалить
  13. @имя:

    по-моему, ты сейчас пишешь о тим-лидере.

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

    ОтветитьУдалить
  14. я специально назал не должность, а потребность/необходимость/роль

    они могут быть по-разному раскинуты на должности

    хорошо, пусть тимлид

    и че такое "организованность"???

    неужели для ее изучения требуется усвоить текст более чем в 5 Кбукв (если без воды)?

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

    > и способности работы с людьми

    черт, еще какие-то таинственные способности...

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

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

    я бы предложил тебе написать статейку "почему я не хочу быть тимлидом"

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

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

    P.S. че-то buffovich все обещал че-то интересное сказать, да никак пока не скажет...

    ОтветитьУдалить
  15. @имя:

    >я специально назал не должность, а потребность/необходимость/роль

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

    Поэтому и интересно, чтобы такое я мог бы вписать к себе в резюме.

    >я бы предложил тебе написать статейку "почему я не хочу быть тимлидом"

    Надо попробовать. Но на статью время вряд ли найдется. А вот на серию заметок -- пожалуй соберусь.

    ОтветитьУдалить