Хотел написать о том, как по моему мнению надо писать резюме, но мысль споткнулась на том, что надо перед этим описать как я вообще оцениваю насколько программист хорош или плох. Кстати, я начинал эту тему в статье о технических интервью.
У меня достаточно простой список параметров, по которым я оцениваю насколько программист подходит под какую-то позицию. Вот, что я считаю важное для соискателей
— Наличие мозга
Тут все просто. Если мозга нет, то хоть у человека невероятный опыт (вымученный десятилетиями пыток работодателей), толку из того программиста выйдет немного.
— Понимание архитектуры и хорошего vs. плохого кода
Собственно, это та основная вещь, которая отличает обычно senour от junior программистов. Опытные программисты, чаще всего написали уже столько говнокода, что они таки понимают, почему решение написанное сегодня может быть хорошим или плохим через год.
— Знание платформы
Изучение платформы достаточно тягомотная штука. И если поверхностные знания можно нахватать в течении пару месяцев, то глубинное понимает обычно приходит за год(ы).
— Знание языка программирования
Честно говоря, это вообще не столько важно, при знании все вышеуказанных пунктов. Язык программирование на более менее нормально уровне выучивается очень быстро.
Это был технический список, а вот личностный
— Мотивированный
В общем-то мне все равно чем человек мотивирован. То ли ему интересно, то ли ему хочется заработать на мерседес, то ли он трудоголик. Главное, чтобы человек приходил на работу и хотел что-то делать.
— Умение работать самому
Тут, думаю, многие подымут бровь… Все привыкли к тому, что все работодатели требовали умение работать в команде. Я же ставлю умение работать самому выше чем умение работать в команде.
Вообще, вся эта лабуда с умением работать в команде пошла от корпораций. В корпорациях зачастую работают куча очень средненьких программистов. И быстродействие этих программистов оставляет желать лучшего. Поэтому их и пытаются запрячь по десятеро в упряжку, чтобы везли. Соответственно, нужно уметь работать в команде (читай не кусать того, кто бежит с тобой в упряжке рядом).
У меня больше опыта в маленьких компаниях. И там нету места для упряжек, там приходится везти самому. Так, что уж лучше человек пусть умеет сам работать.
— Умение работать в команде
Таки да, когда человек уже умеет работать сам, хорошо бы, чтобы он еще и умел работать в команде
Пожалуй таки этого списка достаточно, для того чтобы нанять толкового разработчика (если он конечно попадется в сети компании).
Есть желание чего-нибудь добавить либо отнять от этого списка?
P.S. Кстати, сейчас у меня три метода доставки блога есть — RSS, email и livejournal. Есть еще какие-нибудь методы, которые упростили бы вам жизнь (в смысле получение блога)?
А может по началу все же оценить человеческие качества, а потом проф???
Ну, смотря чего хочется добиваться.
Если найти хорошего человека — то да, сначала человеческие качества. Если найти хорошего программиста — то пожалуй сначала проф.
В общем-то эти две шкалы скорее параллельные, чем последовательные. Но, шкала технических качеств более приоритетная.
Как пример:
Немотивированный программист с мозгом как по мне, более перспективен, чем мотивированный программист без мозга.
Блин, насколько же все это обобщено и упрощено. Ну и как мы будем проверять наличие мозга у программиста, штангенциркулем мерять будем? Какого программиста, на какой проект, с каким опытом работы и какими знаниями и скиллами, а так получается что все это разговор про сферического коня в вакууме. Насчет мотивации тоже вот — сначала разработчику было интересен сам проект, а потом цены стали расти и человек элементарно стал задумываться про стоимость жизни и мотивация поменялась.
У нас например было так. Небольшая команда в большой корпорации в Москве, был очень сильный разработчик и с ним было интересно работать, но человек элементарно устал от всего этого и свалил. Надо искать замену -.Net developer. Закинули вакансию, стали ждать. Народу из Москвы пришло совсем ничего, в основном из регионов и Белоруссии. Вообще-то у нас на входе HR на аутстаффе (т.е. кадровое агентство работает в нашем же офисе и ищет людей под проекты), оно же проводит первичную фильтрацию. Т.е. эти люди изучают наш проект, выясняют требования к проектам и людям, потом ищут и к нам поступают более менее подготовленные люди. А потом уже нас технарей отрывают от работы и заставляют их собеседовать. Я так скажу, за те час-два что проводится интервью просто нереально оценить человека, ни один тест не покажет на что способен человек, к тому же любое собеседование это стрессовая ситуация и это тоже влияет. Будь моя воля я бы пригласил человека поучаствовать в проекте месяц другой с оплатой разумеется, но надо понимать что проекты могут быть такой сложности, что там срок вхождения может измеряться месяцами (по верхам-то может и за месяц можно управиться, но глубое понимание самого проекта и его целей займет все-таки больше времени). В основном приходили люди лет по 27-30, с опытом работы где-то в районе 5-7 лет. У некоторых резюме просто переполнено техническими терминами, читать такие резюме тяжело, особенно когда там надергано из кучи областей, вплоть до фотошопа. У меня у самого в начале карьеры такое резюме было, а сейчас я уже не могу позволить себе в резюме лепить такое. У некоторых нет опыта работы с нужными нам технологиями, с платформой. Кто-то показался нам необщительным, я бы даже сказал нежелающим отвечать наши вопросы или делающий это так, как будто делает нам одолжение. Решили остановиться на человеке, который просто нам будет приятен, с которым просто будет приятно работать. Вообще надо делать как Брин, принимать людей которые сильнее тебя, которые знают что-то что ты не знаешь и в этом случае эти люди сделают тебя сильнее, вот только выяснить их силу на первом собеседовании бывает не просто. Сертификаты? Ну есть соседних командах сертифицированные спецы, но по мне сертификация это всего лишь способ заполнить недостающие области в процессе подготовки к оному. Я знаю много людей, у которых нет сертификатов и никто из них не горит желанием его получать и они гораздо сильнее сертифицированных, по крайней мере я уверен что не слабее. Что касается работы в команде, то в больших корпорациях их собирают не потому что работает много середнячков. Просто проекты могут быть таких масштабов и требовать такой надежности и работы там может быть столько, что один человек ничего сделать не сможет. И более того, представьте что в большой корпорации у вас работают не команды, а куча разработчиков-одиночек. Вы же сойдете с ума, пытась управлять этим стадом котов. И кто вам сказал, что в корпорациях работают средненькие разработчики? У нас например раньше было выгодно разработку размещать в Индостане, а сейчас уже нет, так как там оклады тоже растут, плюс выясняется что гораздо выгоднее иметь небольшие команды из сильных спецов, чем стадо посредственностей. Просто сильными людьми надо уметь управлять, а это мало кто умеет делать. К тому же я знаю людей, которые хорошо умеют работать самостоятельно, только за ними приходится следить, чтобы они не «насрали» лишнего в CVS при командной работе.
Все эти пункте написаны настолько в общем, что по каждому можно дать отдельный пост-противопоставление. К сожалению нельзя на первом же интервью сразу сказать, подходит тебе человек или нет, к тому же сам субъект наблюдения влияет на объект и не всегда человек, проводящий интервью действует в интересах компании, так как все мы люди, все мы человеки. Иногда бывает, что самое первое впечатление о человеке влияет на весь ход интервью, вплоть до того, как человек пожал тебе руку в самом начале и ты уже выстраиваешь к нему оценку. Вообще я стараюсь всячески дистанцироваться от проведения интервью кандидатов, так как я не считаю, что способен адекватно оценить кандидата, адекватно в отведенное время понять его. Вообще я бы брал всех кто прошел первый уровень нашей обороны, так как язык программирования можно выучить на стороне и самостоятельно, но каждый проект настолько уникален и требует самых разных знании, что требовать от людей знать все просто невозможно.
К этому посту можно было бы многое добавить, но все это будет лишь частным мнением. Но все таки я бы выкинул все эти требования и оставил бы один — насколько человек которого я собеседую сильнее чем я, сильнее ли он вообще чем я. И уже исходя из этого пытаться выяснить, сильнее ли он чем я и в чем. Не смотреть на сертификаты, на опыт работы, а просто попытаться прогнать его по всем предметам, которые я знаю, в которых я дока и попытаться понять, в какой из них он сильнее чем я. Знает ли он ответы, которые знаю я, еще лучше всего когда он знает то, чего не знаю я. Это кстати совет тем кто проходит интервью: если в вашей профессиональной жизни были моменты, когда вас «торкнуло» от чего-то что вы узнали, обязательно это расскажите, всегда приятно видеть людей, у которых с жаром загораются глаза, когда они рассказывают что они делали, как пытались исправить ошибку и какого же было их удивление, когда они узнали что-то, что их по настоящему торкнуло.
Просто пытайтесь найти людей, которые сильнее чем вы. Раскройте их, попытайтесь их раскрыть, прямо спросите их, чем они сильнее чем вы. Они будут задавать вопросы, что знаете вы и даже по этим вопросам вы сможете выяснить их подготовку и те проблемы с которыми они справились. ПРОСТО ИЩИТЕ ЛЮДЕЙ СИЛЬНЕЕ ЧЕМ ВЫ.
Кстати, по поводу
вспоминается заметка про «корпоративную амнезию» в этом же блоге. Видимо, совсем нет (?) людей, которые понимают проект так хорошо, чтобы описать его хорошо. Невозможно заниматься развитием и документированием достаточно хорошо. Выбирают развитие. Подскажите мне, пожалуйста, где найти другие мнения, наблюдения.
Ну я по себе судил, если честно. Я год назад пришел в команду проекта, до этого этим проектом рулила еще какая-то команда, т.е. тех посадили на другой проект, а нас перевели на этот. Документация была в wiki, но все равно вникнуть сразу в нее нереально, потом некоторых базовых вещей в документации не было и чтобы хоть как-то все это уложить в голове пришлось ее немножко дополнить. Вообще это биллинговая система, но такой основополагающей вещи как потоки данных в документации не было или мне не удалось ее найти. Ну хорошо, есть люди, которые понимают как все это работает, но документирование требует времени и усилий и как вы предлагаете выходить из этой ситуации? Никто ведь, ни у нас, ни на западе не считает издержки на отсутствие документации или лучше сказать, не считает издержки из-за ее низкого качества. В компаниях для которых софт это бизнес, там да, там без этого невозможно и там для этого люди есть, но в непрофильных все не так. Я бы вообще документирование вводил отдельным непересекающимся проектом, чтобы в голове у разработчиков не происходил клинч из-за того, что приходится по разному мысли когда пишешь код и когда описываешь что этот код делает.
Больше всего похоже на крик души 🙂
> Просто ищите людей сильнее чем вы.
Я отвечу словами из вашего комментария:
«штангенциркулем мерять будем?»
Например человек знает технологию какую-то лучше чем вы. Сильнее ли он вас? А если эта технология нафиг не нужна в этом проекте.
Я согласен, что нужно нанимать людей сильнее, но это кстати не отменяет того, что я описал в посте.
Теперь попытаюсь разбить ваш ответ на несколько частей и ответить
— Вы много говорили, что нету объективного метода оценить насколько хорош программист по интервью.
Я с этим полностью согласен. Однако это не отменяет того, что мы можем пытаться отранжировать качества которые мы хотели бы видеть (как я сделал).
— Насчет больших корпораций и умения работать в команде.
Зачему, я не выкинул вообще это умение. Просто я поставил его ниже чем умение работать самому. Ну не верю я , что человек умеет работать в комманде, если он не умеет работать сам.
— Поиск людей лучше себя.
Тут вы перечете себе. С одной стороны вы говорите, что за интервью нереально нормально оценить людей. С другой стороны вы говорите «Раскройте их».
И насчет вопроса, чем человек сильнее вас… Человек вероятнее всего первый раз в жизни вас видит, как он может сказать, чем он сельнее.
умение работать в команде!!
…умение работать в команде, это оч важно тк проект ведется нес-кими людьми и с ними нужно как-то кооперировать, спрашивать часто бывает полезнее чем тужиться и постигать это в одиночку 🙂 это совсем не зависит от маштаба проекта, как правило ТЗ пишется другим чел. и даже с ним нуно как-то ладить ))
Я не говорил, что оно совсем не нужно. Я говорил, что в начале (более важно) человек должен уметь сам решить проблема, а уж потом работать в команде.
Начали за здравие, закончили за упокой. (c) В смысле, начали о черезмерном упрощении и закончили еще большим упрощением и обобщением. 🙂
Искать людей которые сильнее нужно если ставится задача повышать уровень всей команды. В наших же (украинских) реалиях HR-ам чаще приходиться брать на свободные вакансии хоть кого-нибудь. Не буду говорить о том как мало сейчас кадров: вы и сами об этом знаете. Если ограничиваться при приеме на работу только теми кто сильнее то есть риск так никогда и не найти хороших кандидатов на вакансию.
Согласен, наверное надо искать золотую середину, да и далеко не всегда нужны сильные разработчики, достаточно чтобы человек просто работал и умел делать свою работу, достаточно того, чтобы не пришлось за ним тут же переделывать (со временем конечно все приходится переделывать за всеми) и не приходилось контролировать каждый шаг.
По Бруксу добавление новых людей в команду начиная с некоторого этапа только замедляет скорость команды или отдельных ее членов. Мне кажется, что внедряя в команду неподготовленных людей мы заставляем остальных разработчиков возиться с ними, объяснять им какие-то части проекта, показывать азы, иногда люди не могут IDE настроить, сервер локально поднять. Оно конечно лечится и с ними лучше чем без них, но осадок остается, когда проект не поднимается или не работает, например по какой-нибудь глупой ошибке новичка. Да, если хотим поднять уровень команды — нужны сильные, но с другой стороны если снижать планку есть риск что уровень команды понизится и вместо проработки архитектуры и тестировании сложных вещей senior разработчики будут постоянно натыкаться на мелкие ошибки.
Вообще мы искали senior, может быть поэтому я сделал упор именно на людей такого уровня.
Есть просто неплохие разработчики.
С одной стороны, они умеют нормально решать проблемы. С другой стороны, они могут быть и не сильнее человека, который их нанимает.
Как по мне, таких нормальных разработчиков в фирме должно быть 80%.
Остальные 20% действительно должны быть как можно лучшие разработчики (в идеале, чтобы они были сильнее тех, кто уже есть в команде).
А если они не могут настроить IDE или не понимают язык программирования, то это не разработчики вообще.
Предидущий коментарий был ответом на большой комент андрея.
Виктор Ронин, пожалуйста поправьте уже этот баг вордпреса с коментариями. Лично меня здорово напрягает и думаю не меня одного.
Та да… Надо таки его добить. (баг)
На мой взгляд, очень правильные требования.
Кроме умения работать самому, и если человек будет работать не в одиночку, очень важно (а не только «хорошо бы»), чтобы человек мог нормально взаимодействовать с окружающими. Иначе непонятно что получается.
А кроме мотивированности ещё необходима мотивация со стороны работодателя — на своей долго не продержишься 🙁 Но это уже не по теме.
Я бы сказал, что работодатель, должен не мешать и слегка помогать.
В остальном, внутренняя мотивация, гораздо сильнее внешней.
Шаблонно, негибко, просто и (быть может) даже примитивно.
Всё субьективно, и не может нести реальной оценки, разве что только для стандартной личности, не способной дать динамику развития.
Написано круто.
Тем не менее, собеседование требует какого-то шаблона с которым сравнивается соискатель.
Может быть для самых высоких позиций, шаблоны должны убираться, но когда собеседование проводится с обычным программистом, на обычную позицию (что достаточно часто) то шаблоны — это то, что нужно.
— Наличие мозга
Проверяю вопросами по сути предыдущих проектов — концептуальный дизайн, описание сложных функций.
Вообще под этот термин можно подвести многое, в том чесле аналитический склад ума, умение удержать масштабную модель в голове, умение делать выводы с несколькими вариантами при недостаточных исходных данных (функциональный анализ).
— Понимание архитектуры и хорошего vs. плохого кода
Человек либо умеет разрабатывать ПО нужного мне класса, либо не умеет. Если у человека есть в запасе только процедурный подход (скриптовые языки), то на проект с таким подходом я его возьму. Если человек имеет навыки (а не только теоретические знания) по работе с СУБД, то на проект, где основная логика лежит на сервере и тесно связана со структурой данных — тоже возьму. Абстрактное знание набора паттернов — bull shit.
Аккуратность в оформлении кода — большой плюс. Но неаккуратный код в моей практике лишь снижает скорость разработки. Потому что я выделяю время на приведение вервого черновика в божеский вид в любом случае. Со временем разработчику становится лень п нескольку раз переписывать то, что и так работает, и он сразу пишет аккуратно. Либо увольняется.
— Знание платформы, — Знание языка программирования
Не разделяю. Скилы либо есть, либо нет. Если нет, резюме не проходит отбор. Если есть, но на собеседовании оказывается, что нет, человек получает моральный пинок, и (надеюсь) к следующему собеседованию резюме становится честнее.
— Мотивированный
Это по резюме определить невозможно. По умолчанию, человек ищет работу, и раз пришел на собеседование, значит наше предложение его привлекает. В ходе собседования выясняю ВСЕ (по возможности) стремления человека на этот и два следующих года. Сразу же сопоставляю с реальными условиями в компании и планом личного развития, обсуждаем, и тем самым создаем почву для мотивации. Если несовпадений много, расстаемся. Сильно менять устремления человека, либо изменять планы компании по результатам собеседования никто не будет 🙂
— Умение работать самому, — Умение работать в команде
Must be.
Проверяю аналогично «мозгу», вопросами по сути предыдущих проектов, но уже с уклоном на огранизацию личной и командной работы. Студентов без опыта работы не беру.
>Знание платформы, — Знание языка программирования
>Не разделяю. Скилы либо есть, либо нет
В смысле не разделяете? Не разделяете, что скиллы нужно проверять?
Я не совсем тут понял.
По мотивации согласен с вами.
Не разделяю на две области проверки.
Платформа (или семейство платформ) и язык (несколько диалектов) разработки для этой платформы — неразделимы. Есть чистый C++ и Java, но это абстракция. Вся сила в существующих решениях, а не велосипедах. Поэтому, если человек писал на CodeWarrior для Mac на С++ (могу ошибаться, слышал краем уха), то на VS 2008 для Win2003 на С++ он писать не будет. На том же уровне. Только через значительный промежуток времени он изучит специфику, потом еще через время определит сильные стороны, которых не видел раньше, потом забудет те приемы, которые применял раньше, но нельзя применять теперь, и лишь тогда начнет улучшать навыки на новой платформе.
А скилы нужно проверять 🙂
Да, согласен разделение слегка искусственное.
Скорее, как я говорил интересовала платформа написания.
Я просто язык отдельно выделил, так как например j2se + swing для windows и VisualStudio + MFC + C++ для windows — очень разные вещи.
Хотя тут пожалуй под платформой нужно понимать именно связку windows + mfc, а не просто windows.
По поводу способа доставки блога: упростил бы жизнь подкаст 🙂
Ну это вряд ли… Это уже не блог тогда будет 🙂
не отображаются картинки почему-то( это только у меня так?
А какие картинки?
Вы практически пересказали мои мысли. Полностью согласен.
> «нанимайте специалистов сильнее Вас»
> «Опыт, умение работать и так, и эдак»
1) Будет сложно управлять командой из гуру сильнее Вас. Ведь они не будут видеть в Вас авторитета.
2) Будет сложно мотивировать overqualified специалистов рисовать интерфейс и делать подобные «мелочи», которые тоже делать кому-то нужно. Я считаю, что человека нужно брать такого, чтобы его знания не слишком-то превосходили должность, которую вы ему предлагаете, иначе ему будет банально неинтересно работать.
1) Заблуждение. Менеджмент — это другая область.
2) Overqualified не нужно брать. При этом, специалисты могут не быть overqualified, и при этом быть «сильнее» менеджера в разработке. Overqualified — это на столько сильное несовпадение в лучшую сторону, что о мотивации здесь и речи быть не может. Лучше всего сравнивать с другой областью компетенции, которая хоть и цениться на рынке больше, чем данная вакансия, но данной компании не подходит.
Я бы чуть по другому переформулировал.
Фактически невозможно набирать людей, которые постоянно сильнее. В интервью чаще всего участвуют наиболее сильные люди. То есть, исходя из этой схемы через некоторое время в компании должны одни гении работать.
Плюс, чем более умел человек, тем меньше шансов его нанять вообще (особенно в компанию, где все слабее него).
Да и вообще, не имеет смысла нанимать overqualified. Так как там где нужен просто тестировщик, не подойдет директор QA. И там где нужен просто программист не подойдет супер крутой архитект.
«А может по началу все же оценить человеческие качества, а потом проф???» нуууу это конечно ты загнал, если у человека есть все личные качества но работать он на этой вакансии неумеет нафиг он тогда нужен, всё таки на первом месте технические характеристики грубо говоря
Как я понял, это относится к комментарию Алекса. Может туда переместить комментарий?»
Проф. качества куются довольно быстро при наличии желания со стороны сотрудника, а вот человеческие — нет.
Я думаю под проф. качества для разных людей подразумеваются разные вещи.
Для меня проф качества включают знания языка, платформы, архитектуры и т.п. И уж во втором эшелоне умение например общаться с заказчиком и т.п. И в такой формулировки выковать быстро — нереально.
Если же под проф качествами подразумевать умение не хамить клиенту и приходить на работу трезвым — то пожалуй таки можно выковать быстро.
Это уже вопрос уровня Ваших проф. качеств, в плане инженерной педагогики.
Те три вещи, которые Вы упомянули учатся очень быстро, если руководство достаточно компетентно и ответственно в подборе персонала.
Понятное дело, что не каждый сможет вообще чему-то научиться. Но у меня был опыт обучения Delphi 4 довольно глупого (пропащего) человека. Конечно банковское ПО ему едва ли под силу будет разрабатывать (по крайне мере без чьей-либо помощи на первых порах), но программы для кафедры теплотехники и для военной кафедры он писал вполне себе не плохо. А обучение заняло мало времени.
Я не хочу чем-либо хвалиться, и Вам совсем не надо сейчас защищаться, доказывая примитивность тех предложений (очень часто люди хаят программы, ни разу не видив их). Это всё и так понятно. Вопрос лишь в том, что грамотно-проведённые сбор, анализ и синтез требований на проект, позволяет дать тому человеку задание (даже удалённо), и получить нормальный результат в обозримые сроки.
Ещё раз повторюсь (ибо есть печальный опыт борьбы с понтами голосящих) — он (и такие как он) не сделают всю интеллектуальную работу, но оно и не надо, ибо вся интеллектуальная нагрузка ложится на большую тройку — бизнес-аналитик, менеджер продукта, менеджер проекта.
Благодрая фреймворкам (в частности .NET Framework) — программистам надо просто исполнять свои обязанности, их работа становится контролируемой (разумеется при грамотном управлении).
Я не хочу никого обидеть, понимаю что у каждого своё мнение (и всем хочется доказать миру свою кроутость). Но я думаю именно так, и опыт(!) показывает что это работает, что это эффективно, это работает. Если у кого-то не получается, что-то — не значит что не получается у всех.
Не согласен насчет быстрых сроков обучения.
На своем опыте и когда меня учили и когда я учил и когда рядом со мной учили.
Если брать зеленого и толкового студента, я бы сказал минимально (с очень напряженным и тщательным обученим) уходит 1 год до того момента когда его под присмотром можно пускать в проект.
Где-то минимально 2-3 года — до того, чтобы человек мог сам проект делать без надзора.
Да, .NET framework частично упрощает задачу относительно C++, но человек у которого не лады с алгоритмизацией и архитектурой, что там, что там такое натворит, что будет страшно.
Плюс, одно дело небольшие программки для кафедры писать (обычно мало требований, никакого тестирования), а другое полновесные коммерческие приложения.
Чувак :))) Я же специально сделал упор в своём комментарии, что задача не обучить человека так, чтобы он в одиночку мог сделать что-то едрёное, мог самостоятельно вести обсуждение с заказчиком, контролировать сроки и т.п.
Для этого всего есть три (как минимум) высокооплачиваемых специалиста.
Моё предложение состоит в том, что если программист будет кодером, то разработка будет стабильной. Если кто-то из кодеров делает лучше (чем было задано), значит с ним надо работать уже не по шаблонным схемам, но это уже другая тема обсуждения.
Если доверить программистам полновесное коммерческое приложение, то оно будет провалено, да так провалено что без полной переделки не обойтись (исключения бывают, знаю, можно не напоминать).
Предположим, что вам нравится торт «птичье молоко» такого-то комбината. Вы каждую неделю покупаете экземплярчик и потребляете вместе с семьей. Кушаете и не удвиляетесь — он каждый раз столь же прекрасен как и в предыдущий.
А ведь там меняются кадры, приходят студенты (с кулинарных колледжей) и т.п.
Их задача не сделать так, как им хочется, а сделать так как надо.
Полностью аналогично и тут — задача программиста делать, а не творить.
В плане языков я имел ввиду как раз не C++, все языки семьи .NET, кроме него. Мне показалось что C++ там оставили для стариканов, которые не хотят (не могу) научиться чему-то другому. Не хочу никого обидеть, да и не важно это.
На сколько непрофессиональны могут быть те кодеры? Зависит от того как Вы продумаете проект — если взять ASP.NET + Monorail то можно брать даже PHP-шников, и круг подходящих людей получается необычайно широким.
Если Вам в какой-то момент потребовалось увеличить штат — проблем не будет. Понадобилось обновить команду — не вопрос. Нужны люди знающие шаблоны проектирования — пожалуйста 🙂
Но вот та группа звеньев (бизнес-аналитик, менеджеры проекта и продукта) — с ними уже сложнее. Их придётся холить и лелеять, посему тут нужны развитые личности, знающие о чести и достоинстве (как бы ни пафосно оно звучало), умеющие уважать и задумываться над чужим мнением.
Самураи в древности обращались к друг другу с помощью суффикса «-доно», который означает «такой же или лучше». Над этим имеет смысл задуматься, как мне кажется.
Алексей, замечу по ходу ты высказал несколько очень хлестких фраз. Мне кажется не стоит так вот все под одну гребенку.
— Моё предложение состоит в том, что если программист будет кодером, то разработка будет стабильной
— Если доверить программистам полновесное коммерческое приложение, то оно будет провалено
— C++ там оставили для стариканов, которые не хотят (не могу) научиться чему-то другому
— можно брать даже PHP-шников
Хм… Выскажу свою мысль по частям
а) Программирование не равно деланию тортов. И есть задачи в программирование, которые очень тяжело разделить на планирование и исполнение. По этому поводу, я писал статью:
http://victorronin.com/2008/03/30/koder-ili-programmist/
Сейчас бессмысленно иметь людей, которые просто умеют набивать код.
б) Я и не говорю, о том, что программист должен общаться с заказчиком. Я говорю о вполне обычном программисте, которому поступают задачи от project/product manager’а и тестируются QA. Может быть даже какие-то архитектурные решения приходят от архитектора.
Даже внутри этого, имея мало опыта можно (и это большинство успешно делают) такое наваять, что мама не горюй.
Так что я просто говорил о том, что для того, чтобы натренировать программиста качественно решать небольшие четко сформулированные задачи нужно 1-2 года. И то, при этом все равно нужно заглядывать иногда через плечо.
в) Так вот, базируясь на а) и б) это только на бумаге хорошо звучит — «понадобилось обновить команду — не вопрос». Реально же, даже в фирме с очень хорошо поставленными процессами, если программистов заменить на студентов с малым опытом, то работа просто станет.
Суммируя. Я за разделение труда — это правильно и верно и упрощает задачи программирования и проблемы обучения программиста. Тем не менее программировать — это не заборы красить и количество необходимых знаний достаточно большое, которое как мне кажется не возможно освоить за короткие сроки.
Кстати насчет студентов и кулинарных изысков.
Вы когда нибудь видели главным повором серьезного ресторана — студента имеющего всего 1 год опыта? Ну ладно, главный повар = team lead по большему счету.
Но даже помошники повара (я уж не помню как называют вспомогательных поваров) в хорошем ресторане редко имеют скажем всего 1 год опыта.
И уж вряд ли повар, возьмет кого-нибудь, кто умел только яичницу делать и скажет… так шо там… фигня, за пол года из него настоящий повар выйдет.
Насколько я знаю, кулинарные институты — те же 5 лет учат. Та ладно с этими институтами, даже курсы больше пол года длятся, которые дают очень поверхностные представления о кулинарии.
Вы не стали вчитываться в тот мой комментарий. Я там говорил о бизнес-анализе, и не совсем том проект-менеджменте, что распространён ныне в наших землях.
Основная ошибка — «Сейчас бессмысленно иметь людей, которые просто умеют набивать код.»
Я же считаю — что сейчас имеет смысл брать только(!) таких людей. Раньше — да, сейчас — нет.
В блоге flash-ripper.net один комментатор очень правильно заметил, что в Европе даже в ведущих ИТ-фирмах большинство программистов — дилетанты, но бизнес-процветатет.
Я не буду толковать это хозяйство, по двум причинам:
1. Оно имеет смысл только в случае непредвзятости оппонента.
2. Чтобы не получилось слишком много букв.
Задуматься стоит хотя бы потому, что PMBOK и BABOK не появились бы на пустом месте и без особой надобности.
На самом деле, комментарий прочел несколько раз.
>В блоге flash-ripper.net один комментатор очень правильно >заметил, что в Европе даже в ведущих ИТ-фирмах большинство >программистов — дилетанты, но бизнес-процветатет.
Сейчас работаю в США. Насчет Европы точно не знаю, но могу рассказать как бизнес процветает.
а) Стартуются 10 фирм и нанимают туда очень слабеньких программистов (так как денег на большее нету)
б) Все 10 фирм получают венчурные инвестиции и нанимают уже средних программистов
в) 9 из 10 фирм умирает
г) Одна фирма (выжившая) таки находит своих клиентов в него еще больше вливается венчурных денег
л) Из стартапа выгоняет предыдуших программистов, нанимают более дорогих и толковых и они разгребают говно код написанный на стадии а, б и в).
Так что ключ к успеху бизнеса это не бестолковость программистов, а венчурное инвестирование, а слабые программисты это всего лишь побочный эффект того, что на этапе а) денег у стартапа все еще мало.
P.S. Я согласен, что разделение задач уменьшает время необходимое для обучение программистов. Однако, оно хоть уменьшает, но все равно оно достаточно большое.
Осмелюсь предположить, что Вы малость упустили «искусство мотивации» и «бразильскую систему»?
Конечно, если Вы берёте рядового москвича, с завышенным самомнением, отсутствием мозга, нормально обеспеченным родителями — глупо расчитывать на его заинтересованность. У него и так всё есть.
Честно говоря не совсем понял, причем тут москвич.
Вроде последняя ветка обсуждения у нас была по поводу того, почему фирмы успешные или нет.
http://victorronin.com/2008/06/30/programmistskij-sinxrofazatron-chast-3/ — вот об этом я и толкую. Работу программистов измерять не просто можно — нужно.
Не надо говорить, что нельзя. Говорите, что у Вас пока не получалось. Именно у Вас, именно пока ещё. Это первый Ваш шаг к решению проблемы.
Это мой способ развития и решения того, что раньше у меня не получалось. На мне работает, можно и Вам пригодитья (отказаться — всегда успеете).
🙂
А я вот говорю, что нужно, да вот толком не выходит. Все методы измерения работы чаще всего натыкаются на то, что программисты начинают делать не работу а накручивать свои характеристики внутри этой системы.
>Именно у Вас, именно пока ещё.
Я просто счастлив, что весь остальной мир давно решил эту проблему.
Придираться к словам, понимать дословно — говорит о челевеке только отрицательные вещи.
Я говорил о механизме. Камень и монетка падают с одинаковым ускорением, хотя внешне и внутренне отличаются 🙂
К словам пытался не придератся, я просто продолжил аналогию.
И показал, что даже в проведенной аналогии есть проблема с «быстрым» обучением молодых кадров.
[…] вещь я пытался объяснить Виктору Ронину. Дальше написанного он ничего понять не смог (не […]
[…] о проданных товарах, на самом деле к чему я веду к оценке людей которыми менеджер […]
?reddish’s corporation provides chosen to perform inside the tight guidelines of
the appropriate framework.