- разработчик должен знать какого уровня железо требуется для проекта (CPU, память и т.д.). Если вдруг, рабочий ПК тормозит, то разработчик должен (ну просто таки обязан) разобраться в чем дело
- разработчик должен принимать самое активное участие в усовершенствовании процессов на уровне проекта и на уровне организации
- разработчик должен заниматься тестированием
- разработчик должен в совершенстве владеть всеми технологиями, применяемыми в проекте, и по другому просто не может быть
Ну и много чего еще:)
Удивило меня не то, что программистов вовлекают в активности на прямую не связанные с программированием (например управление проектами, управление инструментарием и т.д.). С этим все ясно - универсальный солдат, работающий за еду это мечта любой организации; Но удивило то, что это считается само-собой разумеющимся и не подлежит никакому сомнению.
Гы-ы :) как программист хочу сказать следующее (и думаю, многие меня поддержат)
- Я не умею читать мысли, и если по чьему-то мнению я 'должен что то сделать', то, как минимум, озвучте это пожалуйста. И лучше не один раз.
- Я нанимался на работу 'Java developer'. И я не хочу заниматься выбором железок или решением проблем с кондиционированием помещения. Сори, но у меня нету ни желания ни возможностей заниматься подобными вещами.
- Наивно полагать, что люди всегда делают именно то что надо и именно так как надо.
Момент №1: если что то можно не делать, то это не делают. Исключения бывают в 3 случаях:
- 'выполнение этого требуют'
- 'из этого можно получить пользу (для себя, для проекта, сейчас или в будущем - это уже подробности)'
- 'это нравится или интересно'.
- Насколько я понимаю, в задачи управления помимо пунктов 'подумать-придумать' входят пункты 'донести свои планы', 'обеспечить необходимым' и 'проверить/проконтролировать выполнение'. Вот про последний пункт часто забывают.
тут возможно несколько вариантов, как всегда впрочем. итак
ОтветитьУдалить1) знать какое железо нужно. скажем не должен - может. и таки желательно, чтобы знал. если ты профи, то кто кроме тебя знает, какая именно конфигурация нужна для тех или иных задач? другое дело, что производители железок и особенности их работы уже не задача разработчика. но общая конфигурация - это инструмент. и профи, если он конечно профи, должен знать, какой инструмент ему нужен. но может не знать, тогда прийдется работать на том, что дадут.
с тормозами примерно та же ситуация. по крайней мере внешне установить причину можно. в противном случае прийдется ждать, когда у техников появится время на диагностику, стендовые испытания, временная машина... и, кстати, на стенде может и не тормозить, так бывает. но можно конечно пойти на принцип "я разработчик, а железные проблемы дело техников", но это не эффективно
2) участвовать в усовершенствовании процессов. опять таки, не должен, может. и если разработчик, техник, менеджер, директор этого не делает, то значит его все устраивает. три принципа С.П. Королева
"есть что сказать - не молчи
кртикуешь - предлагай
предлагаешь - делай"
остальное болтовня и брюзжание, не эффективное и демотивирующее
3) тестирование. смотря каким. юнит- и интеграционным должен. это часть должностных обязанностей. более того, должен заниматься частичным смоук тестирование. чтобы убедиться, что написанный модуль работает
4) разработчик должен в совершенстве владеть технологиями, применяемыми в проекте. совершенно правильная мысль. по другому быть может, но не долго. иначе такой "разработчик" для проекта бессмысленен
5) про чтение мыслей. да, должна быть полиси. не на словах, в виде документа
6) про выбор железок. да, это как-раз дело техников. но по-моему тебя никто не заставляет
7) про результаты труда. люди должны четко понимать, что если они не будут делать так как надо и то что надо, то они нафиг не нужны на своем рабочем месте. у нас (в ИТ вообще) увольняют редко, а зря
8) про задачи управления. все так. проверкой и контролем выполнения на разных уровнях являются разные вещи. никто не будет приходить к тебе лично и спрашивать, как ты, яхонтовый мой, поживаешь? все ли тебе понятно? все ли делаешь в соотвествии с полиси? не дует ли, может быть подушечку подложить или сопельки подтереть?
для тимлида критерий - работающий код и проходящие юниттесты. в идеале зеленый репорт чекстайла + пустой репорт code review
для ПМа критерий - рабочий продукт и customer satisfaction. выполнение проекта во время, без превышения бюджета, согласно требованиям
для Senior PM/Product Manager критерий - правильно заполненая, своевременно обновленная проектная документация. с указанием всего от ролей до конкретных людей, включая перечень необходимых скилов и знания, накопленные за время реализации проекта. главной целью здесь уже стоит исключить "фактор автобуса", чтобы можно было в минимальные сроки заменить любого человека на проекте
для СТО критерий - диаграммы велосити, построенные на основании количественных метрик успешности проекта. в этом случае довольно легко найти тот необходимый и достаточный минимум как документов, так и иноформации в этих документах, чтобы с одной стороны добиться повторяемости процессов, с другой стороны облегчить их как можно больше
и единственный человек, с которым может быть будет контактировать разработчик - это тимлид. и контактировать разработчик с ним будет только тогда, когда он делает что-то не правильно. иначе нет никакого смысла разговоры разговаривать. вот такие бездушные и меркантильные огранизации эти ИТ-конторы.
да, почти все правильно. Но спорные моменты есть. Например, я очень сильно сомневаюсь что каждый разработчик владеет в совершенстве a) приемами проектирования (в т.ч. и проектировании БД) б) языками\технологиями всех уровней (HTML+JS+CSS)/Flash/Java/и дальше) в) умеет (опять же делает это очень хорошо) устанавливать и администрировать различные сервера. Если бы так не было, то на проекте не выдели ли бы команты GUI, backend, тестирования и т.д.
ОтветитьУдалитьПо поводу статьи. Перечитал еще раз, и понял, что без знаний подробностей разговоров, пост теряет смысл (а скорее всего, выглядит довольно неоднозначно и идиотски). Поэтому его стоит воспринимать скорее как крик души.
А по поводу конкретно моего случая, есть 2 мысли:
1. Я считаю совершенно неправильным говорить 'это нужно делать', но при этом забивать на 'это', причем забивать систематически и на всех уровнях (исполнители не выполняют; управляющие знают это, но либо игнорируют либо даже поощряют; и все дружно шутят 'у нас как всегда и как у всех!').
2. Наблюдается некая 'имитация кипучей деятельности'. Судя по всему, для решения некоторых проблем, 'тревожных звоночнов' и долгих объяснительно-вопросительных переписок не достаточно. Для этого нужно создание парочки негативных реакций и парочки увольнений.
Вообщем, привет 'квалифицированному' и 'меркантильному' управлению, и желаю удачи в поисках кадров.