Показаны сообщения с ярлыком управление. Показать все сообщения
Показаны сообщения с ярлыком управление. Показать все сообщения

воскресенье, 31 августа 2014 г.

Передача знаний: о зрелости, врагах и жертвах



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

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

воскресенье, 11 мая 2014 г.

Ролевые Игры: Аттестация, Демотивация или "Олег, ну ты же все понимаешь..."


Людям свойственно играть в игры. Особенно удаются - ролевые. Людям нравиться представлять себя великими людьми, просветленными лидерами, мудрыми специалистами, на крайний случай - удачливыми сантехниками или не менее удачливыми домохозяйками. Гм...

Набор профессиональных ролевых игр достаточно разнообразен. Игры в руководителей и подчиненных. Игры новаторов и консерваторов. Есть еще игры в собирание подписей - они особенно популярны в крупных компаниях. Сегодня я хотел бы поговорить о такой замечательной ролевой игре, как аттестация сотрудников. Эту игру также называют оценкой производительности или, на иностранный манер - Performance Review.

С замечательной игрой Аттестация я сталкивался на всех этапах своего профессионального взросления. На всех 4,5 местах работы, где мне посчастливилось проработать (половина - это тот самый случай, когда человек возвращается на свое предыдущее место).  Постсоветская оборонная компания, мелкий аутсорсинг, ИТ центр крупного международного банка и стартап (затянувшийся, правда, на 10 лет) - ограниченно, но достаточно, чтобы понять какие правила хочется видеть в игре с целеполаганием и оценкой сотрудников.

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

Если предположения работают и в других областях (например в компаниях разработчиках коробочных продуктов), это будет мне плюсом, если нет - оговорка сделана.

понедельник, 5 ноября 2012 г.

Неабстрактный менеджер в защиту метрик


Lesson 198. There’s nothing more dangerous than a vice-president with statistics
Lesson Learn in Software Testing

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

Одна из последних прочитанных заметок в очередной раз напомнила о проблеме (прям цитирую):

Истина проста: метрики для оценки сотрудников внедряются в ситуациях, когда у руководства есть проблемы с управлением

Это не так. Или - не всегда так. Я учитывал и вводил метрики для оценки производительности своих подчиненных не когда  были проблемы, а для того чтобы проблем не было. 

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

понедельник, 29 октября 2012 г.

Тест стратегия в одной картинке

Небольшая победа первых 90 дней на новом месте - определил стратегию тестирования.  Ну, или - нарисовал.



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

Теперь можно покрасить красным - что еще предстоит внедрить или желтым - что документировать и двигаться к лучшим временам.



воскресенье, 30 сентября 2012 г.

Менеджер под разным углом зрения


Три обязанности менеджмента: эффективность организации, в которой трудится менеджер, 
стремление сделать работу производительной, а работника — результативным, 
а также управление социальным воздействием и социальной ответственностью.
Питер Друкер. Менеджмент

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

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

Чтобы было на виду - чем нужно заниматься, чем можно заниматься, и чем хочется заниматься (это тоже полезно знать - чем хочется заниматься).

пятница, 29 июня 2012 г.

Начальники с Марса. Подчиненные с Венеры.


Закончил читать книгу "Мужчины с Марса. Женщины с Венеры" Джона Грея. 

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

Очередной поток мыслей переформулированных цитат показался занятным.

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


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

Люди испытывают душевный подъем и прилив сил когда чувствуют себя нужными.

воскресенье, 29 января 2012 г.

Люди с небес


Так совпало, что я прочитал книгу о воспитании детей (или для воспитания детей - пока не определился, как правильно) и одновременно мне выразили доверие возглавить небольшую горизонтальную команду тестировщиков. 

Не скажу, что это первое доверие, но с каждым таким опытом растет  случается переосмысление уже вроде бы сформированных правил и предубеждений об управлении. 

C прочтением книги "Дети с небес" у меня осталось стойкое убеждение, что многие советы из книги подходят и для обычных взрослых - как менеджеров, так и подчиненных.  В книге несколько раз встречалась фраза "советы для детей всех возрастов". Дети бывают всех возрастов - бывают малых, а бывают - и взрослых ))))

Собственно после прочтения у меня появился список реформулированных правил "Люди с небес". В большинстве своем "родитель" я пропускал или заменял на "менеджер", а слова "ребенок", "дети - на "люди" или "человек".

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

суббота, 20 августа 2011 г.

Самиздат - Управление для творцов


В новой команде число разработчиков растет. Планируется к концу месяца иметь 6 против 2 тестировщиков.

Если учесть еще региональную поддержку (они тоже часто программируют), то число разработчиков становится уже 11.

Если учесть второй проект, который под приоритетом 2, то разработчиков становится уже 15 на нас 2. Если учесть, что я в проекте 3 месяца, а коллега вышла в две недели назад и потом неделю проболела, чувствуется приток адреналина с каждым днем обратного отсчета (на картинке наш обратный отсчет).

Ощущаю тестировщиков узким местом. Это вдохновляет на подвиги, но стараюсь больше думать на будущее, а не страдать трудоголизмом. Одним из способов поиска по прежнему является чтение. Стал тщательнее отбирать литературу. Вышел на интересный ресурс из старого доброго самиздата Мошкова Управление для творцов - Андрея Степенко. Также нашел ЖЖ-ку Практика ТОС того же самого Андрея.

Из полезного в ресурсе:
- кейсы 
- переводы
- мысли

Особо радуют переводы книг, которых не смог еще найти в электронном виде.

Делюсь ибо полезно для толстых тестировщиков в узких процессах.

понедельник, 27 июня 2011 г.

Цитата недели: Трудоголики – не герои. Они не берегут время, они просто сжигают его. Настоящий герой уже давно дома, он нашел более быстрый способ завершить свои дела.


Трудоголики – не герои. Они не берегут время, они просто сжигают его. Настоящий герой уже 
давно дома, он нашел более быстрый способ завершить свои дела.  


Дэвид Хайнемайер Хенссон, Джейсон Фрайд
Rework: бизнес без предрассудков.

понедельник, 6 июня 2011 г.

суббота, 28 мая 2011 г.

Кто виноват?


Кто виноват в том, что баг пропустили?

Риторический вопрос.


Наверное разработчики, потому что они баг посадили.


Или, быть может, тестировщики, потому что они баг пропустили.


А может быть менеджер? - он су..а, времени не дал, чтобы нормально запрограммировать , а потом протестировать.


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

среда, 11 мая 2011 г.

Цитата Недели: Чашка или стакан — структура, позволяющая пить более удобно. Но чашка не диктует нам, что именно мы должны пить. Эдвард ДеБоно. Серьезное Творческое Мышление

Правила, Методологии, Стандарты, Бест-Практики, Шаблоны - все это, как правило, строгие структуры с большой буквы Х, не подразумевающие инициативу. Попытки ступить вправо, влево - вызывают "праведный" гнев "надзирателей". Попытки проявить самостоятельность, расцениваются, как бунт. 

Надеюсь, у вас все совсем не так. Когда то давно-давно-давно молодым специалистом мне пришлось  (к счастью недолго 2,5 месяца) работать в компании, где именно так относились к инициативе. Компания была не айтишная, но элементы такого менеджмента я видел и в других компаниях, проектах, командах нашей отрасли.

вторник, 8 марта 2011 г.

Wiki как информационный гарант безопасности


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

Вас, привлекли в середине первого цикла тестирования (тогда вы еще не знали, что он первый) и стали вторым тестировщиком. Первый цикл закончился тем, что фича Ф1 вернулась в доработку фиксить баги.

Между тестированием фичи Ф2 и Ф3 вы (поскольку первый тестировщик переключен на другие проекты) решаете, что у вас достаточно времени протестировать Ф1 еще раз (разработка рапортует об успешном исправлении ошибок). Этот цикл заканчивает нахождением регрессионных багов.

Для следующего цикла вы обучаете третьего тестировщика и менторите его. Опять регрессионные ошибки.

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

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

У вас осталось 30 минут, чтобы написать письмо с ответом.

В идеальном мире вы конечно же держите руку на пульсе и каждую из Н-цать фич знаете, как свои пять пальцев. В идеальном мире вся документация и все письма и все общение заносится в Jira/Mantis/BugZilla/выбери свою систему. В идеальном мире менеджер общается с бизнесом не раз в месяц, а постоянно. В идеальном мире менеджер не делает вид, что ничего не понимает,  и решает организационные проблемы команды сам. В идеальном мире нет багов, а слово "тестировщик" нарицательное.

Но мы с вами здесь и сейчас. И у нас осталось 29 минут.

вторник, 9 ноября 2010 г.

Планирование и отслеживание тестирования для отдельно взятого небольшого проекта


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