Я это в уме держу, когда перечитываю готовые к публикации записи и письма. Тоже самое я внушаю своим ребятам, когда их идеи игнорируются или элементарно режутся на корню. Не очень эффективно, потому что кроме как – “надо быть увереннее в себе!”. Я ничего сказать долгое время не мог.

Но, недавно, появилось несколько мыслей о том, что нужно делать. Источником для них стал разговор с подчинённым. Он обратил внимание на то, что некоторые вопросы решались очень странно на его взгляд. Сначала его просьбу проигнорировали, потом, когда он напомнил отказали, но в итоге он получил то, что хотел. Когда я слушал его, у меня в голове появилась вот такая жизнеутверждающая картинка http://www.youtube.com/watch?v=x1w8hKTJ2Co. Впрочем, раз просьба оказалась выполненной, значит изменились какие-то условия.

Как же использовать это в других ситуациях?

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

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

3. Нельзя заниматься шантажом. “Если фирма (он, вы, все) не… Тогда я уйду (перестану работать, буду писать гневные письма)”. Особенно вредно выбивать особые условия для себя под угрозой ухода. Вполне возможно, что условия будут выполнены, но таким образом себя можно поставить на первое место в списке на увольнение. Нужно быть чертовски необходимым человеком, чтобы позволить себе шантаж… хотя если стоит именно такая перспектива, значит стоит задуматься о соотношении своего мнения о своей позиции в компании и реальностью.

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

Powered by Twitter Tools

Powered by Twitter Tools

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

Руководителю группы или отдела, не важно, один раз в год приходится сталкиваться с вопросами о том, что было сделано важного за год, что делали его подчинённые и что планируется делать дальше. В самом простом варианте предлагается сделать документ, с перечислением предполагаемых улучшений в процессах и инструментах. Это самый не эффективный подход, потому что не каждая фирма настолько стабильна и консервативна, чтобы прогнозы сделанные в начале года оказываются точными под конец, особенно в области разработки ПО. Я с этим сталкивался несколько раз и во многом оценка исполнения своих же планов вызывала уныние. Это подтолкнуло к мысли о том, что систему планирования и прогнозирования стоит изменить, уменьшив период до адекватного размера.

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

Улучшение тестирование планируется по трём направлениям — процессы, методики и инструментарий. Изменение процессов сложное, только если действовать революционными изменениями, если умерить пыл и проводить изменения плавно получается просто и намного тише. Инструментарий в плане внедрения намного сложнее, особенно для обеспечения процессов. Любая формализация ведения задач и отчетности вызывает скрытое сопротивление, преодолеть его хоть и не сложно, но требует времени и много внимания.

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

Общее планирование развития разумно начать с формализации и унификации существующих процессов: что тестеры делают до, во время и после релиза; как нужно вести заметки по работе; и так далее. У меня это вылилось вот в такие пункты документа по улучшениям:

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

Что делать после того, как формализованный процесс тестирования прижился. Следующим этапом нужно начать оптимизацию используемых методик и инструментов. Начать разделение тестовых сценариев на те, что должны быть автоматизированы и те, что остаются в ручном тестировании (в зависимости от цели будет разное насыщение). При наличии автоматических тестов задуматься о необходимости CI, куда можно будет подключить готовые автоматические тесты. То же самое можно будет сделать с тестами на производительность. Если существует слишком много разных инструментов для тестирования, то необходимо провести ревью и убрать дублирующие друг друга инструменты. В перспективе наличие большого числа инструментов приведёт к снижению эффективности и проблемам с поддержкой.

В последующих планах в основном придется оперировать только этими тремя сущностями – процессы, методики и инструменты. Насколько насыщенными будут дальнейшие планы, напрямую зависит от уровня продумывания и исполнения двух первых этапов.

Powered by Twitter Tools

Powered by Twitter Tools

Powered by Twitter Tools

Вкратце манифест говорит о: “Большее значение имеет результаты для бизнеса, чем реализация. Мы отдаём предпочтение техническим решениям, приносящим результат сейчас, чем выгодным стратегически”. Вообще то это ничем не отличается от негласного (подсознательного) манифеста большинства заказчиков.

Такое впечатление, что после манифеста хакера (mp3, eng, The Mentor), у многих специалистов добившихся известности, но жаждущих больше, свербит в голове и напалмом выжигает желание создать свой собственный манифест, но такой, чтобы выглядел посолиднее, внушительнее, а не как этот… эмоциональный, в общем что-нибудь типа Манифеста Agile.

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