Я 8 лет занимаюсь тестированием. Ручным и автоматизированным, в роли тестировщика и тест-менеджера, как сотрудник компании и как представитель аутсорса. И почти на всех проектах сталкиваюсь с одной и той же проблемой: руководители проектов не понимают, зачем им нужно тестирование.

Если задать среднестатистическому РМ'у простой вопрос: «Зачем на этом проекте тестирование?», то чаще всего ответом будет «Ты же тест-менеджер, ты и должна ответить на этот вопрос».

Но ведь приходя в парикмахерскую вы не говорите мастеру «вы сами знаете, что мне нужно»? И в продуктовом магазине вы не просите продавца накидать вам в корзину то, что вам нужно? Вы можете советоваться, вы можете узнавать «а как можно?», спрашивать варианты, но решение всегда за вами. В чём отличие тестирования? Может, в том, что слишком мало менеджеров проектов понимают, зачем оно им?

В этой статье я постараюсь выступить в роли продавца, который показывает клиенту: «а что вообще бывает?» Многие вещи будут описаны, возможно, слишком подробно, слишком просто… Не серчайте, мне просто очень хочется быть понятой :)

Мы решили провести эксперимент и проводить наши открытые семинары еще и через вебинары.

О чем примерно говорить будем?
— Разогреемся мы примером мальтитаскинга.
— Далее мы поговорим о 2 очень разных путях создания «Value to people».
— Поговорим о том, что есть менеджеры, почему идти туда нужно осознанно и подготовленным. О том, как это обычно бывает. О том, почему вменяемый менеджер это большая редкость.
— Поговорим о том, какие менеджеры бывают, почему вам вообще это нужно знать, как использовать это знание.
— Коротенько расскажу современную теорию менеджмента, что такое командная работа. Покажу за счет чего правильная команда «делает» одиночек.
— Немного поговорим о разных типах проектов и почему это важно знать сотрудникам.
— Поговорим о разных типах компаниях, о циклах развитии компании. И снова, с точки зрения сотрудника и менеджмента. Почему это всё важно и как использовать.
— А закончим несколькими удивительными примерами правильного управления, которые на дорогущем 2-ух дневном тренинге Certified SCRUM Master-ом рассказывал очень грамотный дядька Robin Dymond. Надеюсь, меня за это не засудят :)
— Если останется время, я покажу на примерах что такое очень популярные нынче Lean и Kanban. Если времени не останется и вам понравится, я сделаю 2-ую часть. Возможно, вы захотите оставить мне «заявки», о чем бы вы хотели послушать в последующих частях.

Любой проект неизбежно переживает стадию инициирования.

Это на самом деле тот самый момент, когда людям приходит идея. Обычно это идея в виде «а почему бы нам не сделать как … и заработать на этом кучу денег» или «я ничего не знаю про …, но говорят там много денег и я хочу его». Впрочем, иногда проект стартует с четким пониманием того, что именно надо сделать (пусть в общих чертах), зачем это делается и каких конкретно результатов надо в итоге добиться. Такие условия старта – рай для проджекта. Конечно, рай случается не каждый раз и не у каждого. Иногда для этого приходится поработать.

Обычно взаимодействие заказчика и исполнителя каждая из сторон воспринимает как борьбу добра со злом. Мысля себя, естественно, добром. На самом деле, это не совсем так.
Заказчик и Исполнитель – это, скорее, джедаи и ситхи, «белые» и «красные», инь и янь. Они немыслимы друг без друга и никогда не смогут «победить» партнера.

У взаимодействия Заказчик-Исполнитель есть несколько узловых моментов, неопределенность в которых приводит, как правило, к конфликтам и ущербу для проекта. Попробуем их обозначить.

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

Вопрос: Прочитал вашу статью «Социальные аспекты разработки» и был ошеломлен! До этого момента я считал, что такие идеи лишь из области утопий и невозможны к реализации.

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



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

Симптомы: падение дисциплины, низкая скорость разработки, потеря энтузиазма.
Свой же стиль руководства я бы теперь назвал «попустительским».

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

Ответ: В 2 словах это,
— Вносите элементарную организованность в процесс. Это не «пинание» — это ваша работа.
— Разный стиль. С крутыми – искренне, с молодежью – дружелюбно, с «примадоннами» – сухо
— Используйте эмоции для «поджигания» людей. Прочитайте Возьмите эмоции с собой
— Используйте 4 модели руководства исходя из задачи и человека. Это вопросы — Может? Возьмет?
— Готовьтесь к тому, что у вас будут проблемы с Директивным стилем и Делегированием.
— Стремитесь к тому, чтобы у вас в команде были только люди с сильной самомотивацией, для которых ваша работа это хобби, страсть, любимое дело. Помогите разобраться в себе другим людям.
— Сплачивайте команду: cобирайте в одной комнате, проводите общие собрания, ставьте общие достойные цели.

Что такое PMI&IPMI&PMBOK?

PMI (Project Management Institute) – институт по управлению проектами, разработавший систему комплексного подхода к проектированию и организации процессов для успешной реализации проектов. Он предлагает универсальную схему построения работ при начальном планировании, предлагая, возможно даже, исчерпывающую схему этапности, учит правильно строить организационную структуру проекта и контролировать ход его выполнения.

Сегодня я был на семинаре Эдварда Йордана. В первую очередь хочу поблагодарить за эту возможность kotyrev Сергея Котырева.

Тема семинара была «Человеческий фактор в разработке ПО»

Я расскажу про один интересный неоднозначный метод по подбору персонала в IT. Также поделюсь своими ощущениями полученным после семинара.