Да ещё замотивировать их работать в этой области, а не в более прибыльных.
В этом и ошибка «не в более прибыльных». Лучше дать возможность сделать их прибыльными. Хоть на луну, хоть на альфу-центравру пусть строят ракету и продумывают бизнес-план как склиссов пасти на венере. Тогда и толк будет.
Waterfall, в большинстве случаев, и отличается тем, что согласование плана важнее всего процесса, а разработчики «общаются» с заказчиком через менеджеров.
Где тут смайл «биться головой о стену» ?! С какого перепугу вы это решили ?!
А контрольный вопрос такой: у кого знания предметной области в проекте? кто понимает значение термина HairCut для банка? а CMR ее жизненный цикл?
Случаем не ProductOwner согласовывает, что нужно сделать в следующем спринте? Это как-то отличается от «согласование плана важнее всего процесса» иначе процесс тупо станет колом?
Относитель принципов: сами эти принципы бред, если их «трактовать» в лоб.
Люди и взаимодействие важнее процессов и инструментов
Самая наглая ложь, пи... и провокация. Сам Святой SCRUM и есть регламентация… процесса.
Методология, ставящая на первое место людей без соблюдения методологии и «Scrum board» просто… не выполнит своего предназначения. Забавно.
Работающий продукт важнее исчерпывающей документации
Сам по себе product backlog, sprint back log ну и конечно критерии приемки — есть часть документации проекта. Если их не вести и корректно с ними не работать — проект даже не начнется.
Если коснемся вопросов «передачи знаний» при найме нового человека или «умер» участник команды, оценки последствий «а как эта фича повлияет на предыдущие» и что делать если возник конфликт хотелок 5, 8 и 16 спринтами — без вменяемой документации фиг разобраться.
Добавим сюда «разбор полетов» после спринта и, конечно, Burn down chart…
Так что та еще сказка.
Сотрудничество с заказчиком важнее согласования условий контракта
Ну ну… Этим кто-то будет себя успокаивать, когда будет продавать квартиру или почку что бы покрыть убытки клиента согласно условиям контрата :)) Банку будет пофиг, когда потребует возврат кредита с процентами :))
Готовность к изменениям важнее следования первоначальному плану
А вот с этим на 100% согласен. Только есть один нюанс — «водопад» не запрещает вносить измененния по ходу проекта :)
PMBOK (руководство, на котором основывается Waterfall)
Когда уже читать научатся «проповедники Agile», такое впечатление, что специально обманывают.
1.1 Цель Руководства PMBOK®
Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация и/или команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
Иногда и так бывавает.
— Хочу домик отдохнуть.
— Ок. мы их делаем. что именно вы хотите?
— Ну хз. предложите что-то «вы же спец»
— обычно по вашему профилю: делаем домик, окна со стеклом, кухню с газом но вам рекомендуем электричество и подключение к канализации и водопроводом.
— ок. беру.
Прошло Y дней…
— Парни что за хрень вы вы мне впарили, а где я поставлю аквариум с бегемотом ?!
— ?!?!?!?!
Если все «прибито гвоздями» на уровне архитектуры, то потери будут большие.
Если изменения поместятся в какоей-то уже распланированное «окно возможностей» то и незаметит никто.
А с нормальной инструментальной поддержкой — перепланировать в виде «что если» и оценить на что повлияет будет тоже в рамках «текущей работы»
Про собеседование — более менее понятно.
Откройте предложенный выше «Программист 06.001» и какой из упомянутых там пунктов, с вашей точки зрения, лучше продемонстрирует тестовое задание чем собеседование?
Если человек идёт на собеседование на вакансию «программист» и не понимает, что его одна из его основных обязанностей это алгоритмизация задач, то он не программист.
У меня сейчас несколько приятелей проходят обучение на курсах открых при ИТ компаниях, их читают люди работающие в этих компаниях.
Не называя конкретные имена, но кампании уровня ЕПАМ, Luxsoft, СберТехнологии, Яндекс.
Самое печальное в этом всем что им не объясняли ни что такое алгоритм, ни нотации. Так… упомянули один раз. Зато будут программисты Java/C# после курсов, и часть из них себе эти компании… возьмут на работу.
Человек, попавший в «программисты» и начавший свои собеседования может просто не знать о тех требованиях, о которых «знают все» не со зла или «не дееспособный», а потому что не сталкивался.
Вы часто видели в вакансиях что-то вроде: Требуется программист. Минимальные требования «Программист 06.001 5.131118 Утвержден Приказом Минтруда России №679н от 18.11.2013» и " Разработчик Web и мультимедийных приложений 06.035"?
Но для сетевика:
Опыт работы с активным сетевым оборудованием Cisco(конфигурация коммутаторов, маршрутизаторов, не ниже CCNA)
Снимает кучу вопросов.
Можно не устраивать цирк, а просто корректно сформулировать квалификационные требования для вакансии, бережно и уважительно распоряжаясь как своими ресурсами, так и ресурсами кандидата. Вроде все возможности для этого есть. Не жаловаться потом, что приходят неакватные, безграмотные или неквалифицированные люди, которые трятят наше время.
Вы, смею предположить, никогда не устраивались на работу ни токарем, ни водителем, ни даже грузчиком.
Ваше предположение ошибочное. Более 20 лет назад была вторая запись в трудовой при найме. Со всеми должностными инструкциями, подписями в журнале инструктажа по технике безопастности, повышениями квалификации для допуска к работе с новым оборудованием через полтора года и т.д. :)
В моем «производстве» если косяк, то это проишествие категории техническая остановка или авария (масштаба государства) или кого-то просто убьет (благо не массово).
Не знаю как сейчас, но «тогда» просто так приписать себе «3 разряд» было нереально, без атестационной комиссии с протоколом.
У грузчиков — может построже с этим :)
Полностью согласен. Со всеми выраженными мыслями.
Но есть нюанс:
Вакансия водителя? Права категории XYZ
Вакансия токаря? разряд XYZ
Менедждер проекта? PMP certification exam
Cisco? экзамен/сертификат CCNA
Microsoft? MCTS экзамен(ы)
Oracle? Oracle Unified Method 5 Essentials
Список можно продолжать.
Но это все объединяет одно — очерченный набор знаний/требований, которые ссылается в конечном итоге на валидируемый первоисточник (гост/isо/производителя и т.д.)
Почему, когда указывается в вакансии требуемая категоря/разряд/права/сертификат — это нормально.
Как только требуется программист — всплывают «базовые которые все знают» или «зачем указывать, если прочитают перед собеседованием».
Если сравнивать подходы к найму в отраслях, которым более 20 лет и более молодым «программированием» — явно наблюдаются отличия, в стиле «Я Hr/Team Lead — я так вижу» :)
В-третьих, какой смысл в вакансии указывать что я собираюсь спрашивать на собеседовании?
Что бы не «любить моск» тому, кто откликнется на вакансию. Вы же указываете язык разработки? Это нормально предварительно знать требования, нужные в работе. Это нормально обновить «краткосрочную память» перед собеседованием.
Сколько раз было в вакансии одно, в собеседовании другое, а по факту вообще третье…
По факту я спрашиваю либо базовые вещи, либо то что заявлено у человека в резюме.
Базовые для вас или для кандидата? Вы редактировали лично учебные программы учебных заведений которые дают «базовые знания»? Микрософт, Оракл, IBM, Фейсбук. и т.д Вам давали на подпись «Перечень базовых знания для ??? „
Не математик часом? Среди них чаще всего мне попадаются редкостные зануды :)
Нет. Просто приходилось из «своего кармана» оплачивать весь цикл разработки проектов, включая найм или оплату Hr контор, разгребать косяки после ну и бизнес-аналитику делать :)
Так что да… занудствовать приходилось еще как…
Приношу извинения :)
Или «базовый» или «Это не… чётко оговоренный объём обязательных знаний.»
Доктор, Вы уж определитесь :) А то как-то противоречите самому себе.
Точнее, это снаружи может показаться что махровое самодурство :)…
и такие вещи, как стиль работы каждого члена команды, и т.д., можешь даже отдать предпочтение и более слабому кандидату
Это не самодурство. Это нормальный процесс. Если бы эту часть описывали спецы по психологии/социологии они бы выразили это формальными терминами. А поскольку мы не спецы, то и выражаемся как «чайники» в стиле "… тут кампутер Каутион сломался сам..." :)
Отсутсвие общего глоссария :)
Бюдет поиска явно не будет стремиться к нулю. Как минимум операционные расходы для того, кто все это оплачивает :)
Выходное пособие… Если кандидат прошел фильтр испытательного срока, а потом не устроил по какой-то причине, то это уже не суть важно, если такие косяки не единичны.
Надо что-то в процессах найма менять.
Полностью согласен.
Но это все будет понятно при общении, иначе как вы получие пояснения?
Так же, по идее, если мы возьмем информацию о вакансии, исходные данные задания, запись/протокол собеседования и покажем еще ??? «экспертам» мы должню получить точно такой же вывод по результатам собеседования. о пригодности кандидата к вакансии. Это будет объективная оценка квалификации и прогодности к вакансии. Логично?
В противном случае это просто субъективная оценка не понятно на чем базирующаяся. Соответсвенно вопрос о корректности и ценности методологии весьма спорный.
Вы имеете в в иду, что мы не проверяем названные вами способности
У меня складывается мнение, что декларируемые вопросы в «тестовых задания» и реальные вопросы, на которые ожидаются ответы несколько различаются.
Мы не ставим прямо вопрос для заданий навыки формализации, декомпозиции, передачи знаний, но мы оцениваем «знание алгоритов наизусть».
Мы не ставим прямо вопрос рассчитай и обоснуй выбор совего решения, но мы «оцениваем знания шаблонов наизусть»
При этом указать KPI оценки результатов перед тем как дать задание? Да ну нафиг
При этом слепо копируя чужое, не понимая почему именно так вопрос поставлен? вполне может быть что даже порядкок вопросов имеет в чужом опроснике имеет смысл…
По принципу: Спички есть? Значит не стоит…
Мне это зачастую напонимает карго культ, который прикрывается «ну это же базовые знания/ все знают / и т.д...» тупо проецируя свою логику и психологию на кандидата.
это результаты той самой практики, они же не от балды выбирались.
Сколько раз в жизни вы своими руками писали алгоритмы сортировки? А в рамках 3..5 летнего проекта?
Хотите алгоритмичность мышления понять? что мешает взять UML и рисовать себе на здоровье? и карандашик и бумажка и при собеседовании. и дешево и сердито.
В этом и ошибка «не в более прибыльных». Лучше дать возможность сделать их прибыльными. Хоть на луну, хоть на альфу-центравру пусть строят ракету и продумывают бизнес-план как склиссов пасти на венере. Тогда и толк будет.
Где тут смайл «биться головой о стену» ?! С какого перепугу вы это решили ?!
А контрольный вопрос такой: у кого знания предметной области в проекте? кто понимает значение термина HairCut для банка? а CMR ее жизненный цикл?
Случаем не ProductOwner согласовывает, что нужно сделать в следующем спринте? Это как-то отличается от «согласование плана важнее всего процесса» иначе процесс тупо станет колом?
Относитель принципов: сами эти принципы бред, если их «трактовать» в лоб.
Самая наглая ложь,
пи...и провокация. Сам Святой SCRUM и есть регламентация… процесса.Методология, ставящая на первое место людей без соблюдения методологии и «Scrum board» просто… не выполнит своего предназначения. Забавно.
Работающий продукт важнее исчерпывающей документацииСам по себе product backlog, sprint back log ну и конечно критерии приемки — есть часть документации проекта. Если их не вести и корректно с ними не работать — проект даже не начнется.
Если коснемся вопросов «передачи знаний» при найме нового человека или «умер» участник команды, оценки последствий «а как эта фича повлияет на предыдущие» и что делать если возник конфликт хотелок 5, 8 и 16 спринтами — без вменяемой документации фиг разобраться.
Добавим сюда «разбор полетов» после спринта и, конечно, Burn down chart…
Так что та еще сказка.
Ну ну… Этим кто-то будет себя успокаивать, когда будет продавать квартиру или почку что бы покрыть убытки клиента согласно условиям контрата :)) Банку будет пофиг, когда потребует возврат кредита с процентами :))
А вот с этим на 100% согласен. Только есть один нюанс — «водопад» не запрещает вносить измененния по ходу проекта :)
Когда уже читать научатся «проповедники Agile», такое впечатление, что специально обманывают.
1.1 Цель Руководства PMBOK®
Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, что в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов.
«Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация и/или команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.
Крылья… ноги… главное хвост! Цель какая?
Именно — минимизация рисков. От этого строится методология и управление рисками.
— Хочу домик отдохнуть.
— Ок. мы их делаем. что именно вы хотите?
— Ну хз. предложите что-то «вы же спец»
— обычно по вашему профилю: делаем домик, окна со стеклом, кухню с газом но вам рекомендуем электричество и подключение к канализации и водопроводом.
— ок. беру.
Прошло Y дней…
— Парни что за хрень вы вы мне впарили, а где я поставлю аквариум с бегемотом ?!
— ?!?!?!?!
Если изменения поместятся в какоей-то уже распланированное «окно возможностей» то и незаметит никто.
А с нормальной инструментальной поддержкой — перепланировать в виде «что если» и оценить на что повлияет будет тоже в рамках «текущей работы»
Откройте предложенный выше «Программист 06.001» и какой из упомянутых там пунктов, с вашей точки зрения, лучше продемонстрирует тестовое задание чем собеседование?
Хитрая программа ИТ-образования :)
У меня сейчас несколько приятелей проходят обучение на курсах открых при ИТ компаниях, их читают люди работающие в этих компаниях.
Не называя конкретные имена, но кампании уровня ЕПАМ, Luxsoft, СберТехнологии, Яндекс.
Самое печальное в этом всем что им не объясняли ни что такое алгоритм, ни нотации. Так… упомянули один раз. Зато будут программисты Java/C# после курсов, и часть из них себе эти компании… возьмут на работу.
Человек, попавший в «программисты» и начавший свои собеседования может просто не знать о тех требованиях, о которых «знают все» не со зла или «не дееспособный», а потому что не сталкивался.
Вы часто видели в вакансиях что-то вроде: Требуется программист. Минимальные требования «Программист 06.001 5.131118 Утвержден Приказом Минтруда России №679н от 18.11.2013» и " Разработчик Web и мультимедийных приложений 06.035"?
Но для сетевика:
Снимает кучу вопросов.
Можно не устраивать цирк, а просто корректно сформулировать квалификационные требования для вакансии, бережно и уважительно распоряжаясь как своими ресурсами, так и ресурсами кандидата. Вроде все возможности для этого есть. Не жаловаться потом, что приходят неакватные, безграмотные или неквалифицированные люди, которые трятят наше время.
Ваше предположение ошибочное. Более 20 лет назад была вторая запись в трудовой при найме. Со всеми должностными инструкциями, подписями в журнале инструктажа по технике безопастности, повышениями квалификации для допуска к работе с новым оборудованием через полтора года и т.д. :)
В моем «производстве» если косяк, то это проишествие категории техническая остановка или авария (масштаба государства) или кого-то просто убьет (благо не массово).
Не знаю как сейчас, но «тогда» просто так приписать себе «3 разряд» было нереально, без атестационной комиссии с протоколом.
У грузчиков — может построже с этим :)
Но есть нюанс:
Вакансия водителя? Права категории XYZ
Вакансия токаря? разряд XYZ
Менедждер проекта? PMP certification exam
Cisco? экзамен/сертификат CCNA
Microsoft? MCTS экзамен(ы)
Oracle? Oracle Unified Method 5 Essentials
Список можно продолжать.
Но это все объединяет одно — очерченный набор знаний/требований, которые ссылается в конечном итоге на валидируемый первоисточник (гост/isо/производителя и т.д.)
Почему, когда указывается в вакансии требуемая категоря/разряд/права/сертификат — это нормально.
Как только требуется программист — всплывают «базовые которые все знают» или «зачем указывать, если прочитают перед собеседованием».
Если сравнивать подходы к найму в отраслях, которым более 20 лет и более молодым «программированием» — явно наблюдаются отличия, в стиле «Я Hr/Team Lead — я так вижу» :)
Что бы не «любить моск» тому, кто откликнется на вакансию. Вы же указываете язык разработки? Это нормально предварительно знать требования, нужные в работе. Это нормально обновить «краткосрочную память» перед собеседованием.
Сколько раз было в вакансии одно, в собеседовании другое, а по факту вообще третье…
Базовые для вас или для кандидата? Вы редактировали лично учебные программы учебных заведений которые дают «базовые знания»? Микрософт, Оракл, IBM, Фейсбук. и т.д Вам давали на подпись «Перечень базовых знания для ??? „
Нет. Просто приходилось из «своего кармана» оплачивать весь цикл разработки проектов, включая найм или оплату Hr контор, разгребать косяки после ну и бизнес-аналитику делать :)
Так что да… занудствовать приходилось еще как…
Приношу извинения :)
Или «базовый» или «Это не… чётко оговоренный объём обязательных знаний.»
Доктор, Вы уж определитесь :) А то как-то противоречите самому себе.
Это не самодурство. Это нормальный процесс. Если бы эту часть описывали спецы по психологии/социологии они бы выразили это формальными терминами. А поскольку мы не спецы, то и выражаемся как «чайники» в стиле "… тут кампутер Каутион сломался сам..." :)
Отсутсвие общего глоссария :)
А какой набор «чтобы проверить, по возможности, сразу несколько аспектов знаний и навыков» тогда собрались проверять и что заложено в ожиданиях?
Если о знания в предметной области, то это безусловно бонус.
Выходное пособие… Если кандидат прошел фильтр испытательного срока, а потом не устроил по какой-то причине, то это уже не суть важно, если такие косяки не единичны.
Надо что-то в процессах найма менять.
Но это все будет понятно при общении, иначе как вы получие пояснения?
Так же, по идее, если мы возьмем информацию о вакансии, исходные данные задания, запись/протокол собеседования и покажем еще ??? «экспертам» мы должню получить точно такой же вывод по результатам собеседования. о пригодности кандидата к вакансии. Это будет объективная оценка квалификации и прогодности к вакансии. Логично?
В противном случае это просто субъективная оценка не понятно на чем базирующаяся. Соответсвенно вопрос о корректности и ценности методологии весьма спорный.
У меня складывается мнение, что декларируемые вопросы в «тестовых задания» и реальные вопросы, на которые ожидаются ответы несколько различаются.
Мы не ставим прямо вопрос для заданий навыки формализации, декомпозиции, передачи знаний, но мы оцениваем «знание алгоритов наизусть».
Мы не ставим прямо вопрос рассчитай и обоснуй выбор совего решения, но мы «оцениваем знания шаблонов наизусть»
При этом указать KPI оценки результатов перед тем как дать задание? Да ну нафиг
При этом слепо копируя чужое, не понимая почему именно так вопрос поставлен? вполне может быть что даже порядкок вопросов имеет в чужом опроснике имеет смысл…
По принципу: Спички есть? Значит не стоит…
Мне это зачастую напонимает карго культ, который прикрывается «ну это же базовые знания/ все знают / и т.д...» тупо проецируя свою логику и психологию на кандидата.
Сколько раз в жизни вы своими руками писали алгоритмы сортировки? А в рамках 3..5 летнего проекта?
Хотите алгоритмичность мышления понять? что мешает взять UML и рисовать себе на здоровье? и карандашик и бумажка и при собеседовании. и дешево и сердито.