среда, 17 февраля 2010 г.

Как узнать человека за 13 мин?

Вариант 1
Поставьте ему один простой вопрос, выбив его из колеи. А затем поставьте ему ряд вас ключевых для вас вопросов. Посмотрите как он справится с ними.

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

вторник, 16 февраля 2010 г.

Необходимая мотивация

Уже какое-то время с небольшим перерывом волновал меня вопрос мотивации персонала. Основной мотиватор это деньги скажете вы (естесственно не конкретно Вас я имею в виду). Что тут думать - деньги! Собственно, да. Идею пирамиды Маслоу опровергнуть тяжело и деньги обеспечивают основные уровни. Но у меня не было этого рычага сначала напрямую, а затем и косвенно. Приходилось выкручиваться как получалось, но я не был долго готов, чтобы озвучить что-либо вслух (тяжело это дается, когда не можешь не просто сформулировать, а просто или сложно объяснить).
Естесственно при отсутствии материальной мотивации надо придумывать нематериальную.
Сегодня просмотрел одно видео Дена Пинка (Daniel Pink) и перед тем как я постараюсь в двух словах описать как можно сделать мне кажется его стоит послушать. Он и рассказал ту базу, которую я интуитивно попытался достичь, и на чем пытался строить свои идеи. И даже больше :)

четверг, 4 февраля 2010 г.

Автоматизировать можно быстрее

Вот прослушивал один из подкастов ИТ-радио "Промразработка" и мне понравилась высказанная там идея. Она не такая и новая на самом деле, но отлично легла на сложившуюся у меня ситуацию.
Занимаюсь автоматизацией, в том числе, но более плотно и стабильно, последние полгода. В динамично разрабатывающемся проекте. И проблема как положено с изменением тестов, написанных основательно, со своим небольшим высокоуровневым фреймворком.

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

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

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