360: смотри да оценивай

Вот зацепился за методы оценки персонала. Один из них понравился и здесь результат небольшого исследования

Методика 360 ориентирована на то, чтобы получить максимально объективную оценку сотрудника. Основное достоинство «круговой оценки» в том, что она позволяет получить полную картину личностных и профессиональных качеств, знаний и умений сотрудника.

 Ключевые моменты методики:

 Сотрудника оценивают:

• Подчиненные
• Коллеги (те кто находиться на одном уровне иерархии с сотрудником)
• Руководство
• Клиенты (не обязательно)

Оценивание анонимное, при этом указывается только к какой группе оценивания принадлежит тот, кто дает оценку (коллега, подчиненный и т.д.)

Методика позволяет оценить в первую очередь личные и профессиональные качества сотрудника (лидерство, коммуникацию, заинтересованность, инициативность, командность, стабильность работы, качество работы, профессиональный уровень и т.д.) и не предназначена для оценивания уровня знаний (языка программирования, технологии и т.д.)

Оценка проводится раз в полгода/год

Как работает:

1. Для каждой должности определяется свой набор наиболее важных компетенций, качеств (5-15)
2. Для каждого качества определяется свой набор идентификаторов, поведенческих примеров (чаще всего 5, иногда 10)
3. Оценщики, которых обычно 5-15 человек, выставляют по каждой компетенции оценку и потом подбивается статистика.
4. На завершающем этапе результат доноситься до сотрудника и составляется план развития 

Например:

Компетенция – инициативность

Критерии

1. никогда не проявляет инициативу, явно уклоняется от принятия решения по вопросу своей компетентности;
2. инициативу для достижения поставленных целей проявляет крайне редко или проявляет неадекватно решаемой задаче;
3. проявляет разумную инициативу для достижения поставленных целей;
4. стремится постоянно проявлять разумную инициативу, не ждет указаний, инициирует действия;
5. высокая степень проявления инициативы, в любой ситуации ищет и находит творческие подходы для достижения поставленных целей

Я считаю, что применение данной методики было бы целесообразно как минимум для лидов и ключевых сотрудников любой компании. Т.е. на том уровне, когда просто знания языков программирования или технологий становится мало.

 Ресурсы, где можно ознакомиться с методикой 360 более подробно:

• http://nsk.erabota.ru/info/articles/?id=5470
• http://nsk.erabota.ru/info/consult/?id=2035
• http://www.management.com.ua/hrm/hrm049.html

Для меня остались еще открытыми 2 вопроса:

1. Есть ли какой-то софт для автоматизации работы по данной методике?
2. Как проводить ежедневное оценивание подчиненных. Например есть у меня команда человек на 5. Каждый день кто-то отличается в плохую или хорошую сторону, а память она ведь дырявая. Как отмечать успехи своих подчиненных? Ведь такая информация была бы полезна, чтобы отслеживать развитие, направлять и помогать своим подчиненным. 

А что вы по этому поводу думаете? Буду рад услышать кто как оценивает коллег, подчиненных.

Всем доброй ночи

Kanban vs Scrum

Привет всем. 

Сегодня тема не совсем соответствует названию сайта, но я думаю что с автором мы договоримся. 

Последнее время набирает популярности новая техника управления проектами под названием "Канбан", которую как обычно придумали японцы. Вот уж до чего непоседливые. Сегодня я попытаюсь немного рассказать о канбане.

Для начала посмотрим, что нам говорит Вики по поводу канбана. 

Канбан (камбан) — система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».

На первый взгляд не очень-то это относится к программированию и управлению программными проектами. Нужно дополнительное объяснение, а еще лучше практический пример использования. Собственно потому и решил написать пост, что нашел книгу, которая на пальцах, просто и доходчиво объясняет разницу между традиционными скрамовскими техниками и канбаном, а заодно дает понимание, что такое канбан есть.

Вот ссылочка на книгу: Scrum и Kanban: выжимаем максимум от Хенрика Книберга и Маттиаса Скарина. Книга на русском и помогает сделать первый шаг в понимании того, что такое канбан. 

Если кратко, то канбан работает во многом аналогично скраму, т.е. присутствует доска, standup митинги, много общения между разработчиками и т.д. Самое главное, что как и в скраме существует ограничение на количество работы, которую команда может делать в определенный момент и никто не может поменять это объем работы. 

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

Например у нас есть команда: 5 программистов. Ставим ограничение на количество задач в 9. Дальше у нас есть проект с набором задач, количество которых конечно же огромно. Лид (продюсер, владелец продукта) выбирает первые 5 задач и программисты начинают работать над ними. И вот по каким-то причинам они не могут закрыть ни одну из задач, тогда программист, который заблокирован приостанавливает свою задачу и берет новую у лида. Таким образом в работе оказывается уже 6 задач. Если у команды накапливается 9 незакрытых задач, то она больше не может брать новые задачи, а должна во что бы то не стало закончить хотя бы одну из уже взятых задач. Такой подход позволяет увидеть проблемы проекта очень быстро, поскольку мы обязаны завершать все задачи, чтобы получать новые и если где-то образуется затык, то вынуждены его исправлять, а не откладывать на будущее. 

Да новые задачи можно брать в любой момент, когда у вас еще есть лимит, а не только в конце спринта как это принято в скраме. 

Когда же такой подход наиболее приемлем? На каком проекте или на какой стадии проекта?

Я для себя нашел как минимум один тип проекта, когда можно применять такой подход. Это багафикс. Многим из вас наверное приходилось работать на проекте в период багафикса и вы знаете, что скрам при багафиксе работает не очень хорошо. Основная проблема для скрама - это отсутствие фиксированного объема работы, которую можно оценить и взять на спринт. Ситуация меняется каждый день, приходят задачи, которые нужно сделать вчера, начальству плевать на ваши попытки объяснить "что спринт и скрам и вообще..." и весь спринт летит к чертям.

А вот  для канбана здесь никаких проблем нет. Мы определяем некий лимит багов на команду и вперед. Команда может отреагировать на любые изменения и проблемы в тот же день когда они возникли и ваш шеф ходит, и всем хвастается, что у него все на мази, и все идет отлично.

Пост получился намного больше чем планировал изначально, но как-то понесло. Написал прямо на одном дыхании. 

Единственное, что упустил, это слабые стороны и недостатки канбана. Оставлю это вам и буду рад услышать ваше мнение. 

Всем доброй ночи.

Command Window and Macros in Visual Studio. Part 1

Последнее время приходиться писать на Lua, а также постоянно работать с командной строкой.
Лучшим вариантом для редактирования Lua является блокнот Notepad++. Во всяком случае я пока ничего лучше не нашел. Бесплатная лицензия, наличие широкого выбора плагинов, хорошая скорость работы делают его очень привлекательным вариантом. 
Но не хочется переключатся в блокнот, студия ближе, да по ходу работу иногда приходиться править С++ код, искать различную информацию в С++ коде. А в данном моменте студия пока обходит блокнот.

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

Вариант первый - плагин.
Это самый первый вариант, который приходит в голову, особенно когда спишь и видишь славу Visual Assist-а и ReSharper-а. Сразу тянет создать свой аналогичный плагин только под Lua. 
Создал и сел думать, а какой же функционал туда забить. Не придумал, вернее его было так много, что на десяток плагинов хватит. А вот первой ключевой фичи, которая которая потянет за собой остальные я не нашел. Потом я нашел еще несколько причин не использовать плагин:

• неясен функционал

 

• относительно долгий цикл добавления фичей - нужно скомпилировать плагин, перезагрузить его в студии.

 

• необходимость думать о визуальном интерфейсе

 

И тогда я наконец понял, что мне нужно. 

Вариант второй - СКРИПТ.
Но не просто скрипт, а скрипт, который может взаимодействовать со студией, править файлы проекта, получать информацию о классах и т.д.
В качестве отправной точки поисков я выбрал CommandWindow. Здесь меня ждал сюрприз. 
CommandWindow позволяет делать все, вызвать любую команду, которая есть в студии. 

При наборе команды появляется окно подсказка с вариантами команд

Например команда File.OpenFile
Синтаксис следующий "File.OpenFile filename". Причем при наборе имени файла студия тут предлагает варианты, не хуже чем это делают Visual Assist и ReSharper.

Также есть еще одна дополнительная возможность: присвоение команде короткого имени. Это избавляет от необходимости писать длинную команду. Вот вариант короткой команды File.OpenFile

Команда для создания синонима команды называется Tools.Alias или просто alias. Если просто вызвать alias, то можно посмотреть список уже заданных сокращений
Кроме того она позволяет создать синоним для команды с определенным набором параметров. Например после вызова "alias openSealedFile File.OpenFile SealedClass.h" я смогу использовать openSealedFile для открытия файла SealedClass.h

И на закуску еще один бонус - CommandWindow работает в Visual Studio Express Edition

Все это хорошо, но не хватает еще одной вещи - собственно самих скриптов.
И об этом я расскажу завтра
А на сегодня еще один вопрос в качестве домашнего задания: какие еще интересные возможности Visual Studio вы знаете и используете?

Всем доброй ночи.