Отношение команды к работе

Есть пара интересных идей (идеи не мои, но комментарии и мысли все же мои :)), но хотелось бы о ней в свет сказать - может когда-нибудь пригодится

Настроение людей влияет на прямую на их работу ибо напрямую от этого зависит интерес к работе.

Первая: отслеживать настроение команды. Может быть просто ради интереса или веселья, а может помочь для понимая моментов с проколами.

Вторая: Вместе с занесением времени по задачам отмечать отношение к ним: интересно; не интересно; было, но перестало. И соответственно можно получить картину об отношении сотрудника к его работе. Это можно использовать при периодической оценке сотрудника.
Но внедрять лучше только, если действительно отношение человека к его работе имеет смысл и представляет интерес

О пользе коммуникаций

Первый раз прочитал об этом в одном обзоре MSF, когда знакомился с методологиями несколько лет назад. Звучало приблизительно как: вся информация в полной мере должна быть доступна команде.
Многим покажется странным: а зачем? Пусть делают то, что говорят. Я бы сказал не так. Это важно. Как минимум решение зачастую не является единственно верным, т.е. выпросто передаете то, изчего исходили или будете исходить при принятии решения. Они будут видеть ход ваших мыслей, а также сами смогут вам помочь. Информация может быть в каком-то смысле политической (хотя вот в политических вопросах я как раз стараюсь максимально оградить их) и им необходимо строить какие-то свои планы.

Информация должна быть постоянно в движении. Т.е. двигаться и шириться внутри команды, не только от вас ккоманде, но и должно быть наоборот.

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

Главное: делитесь всем что вам становится известным, просите того же от своихсотрудников, поддерживайте процесс движения информации внутри команды, храните ее и подавайте в разных видах.

Enjoy :)

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

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

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

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

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

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

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

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

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

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