Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

Паттерны управления рисками

Управление рисками - несомненно одна из главных задач руководителя проекта. Пожалуй никто не может похвастаться тем, что принимал когда-либо участие в "идеальном" проекте: технический уровень команды был достаточно высок, процесс разработки был выверен и отлажен , требования были детально согласованны и неизменны на протяжение всей работы. Все подобные "неидеальности" невероятно сложно предвидеть и устранить в начале проекта, поэтому в проектном менеджменте их относят в категорию рисков. Существует немало стратегий рискового менеджмента: инкрементная разработка, итерационная, спиральная, водопадная и другие. Все они направлены на то, чтобы получить новую информацию как можно раньше, с тем, чтобы как можно раньше выйти на путь успеха и уменьшить стоимость и время последующих корректировок курса. Можно даже сформулировать универсальную стратегию снижения риска провала проекта:  - внимательно следить за ходом проекта  - определять риски  - работать над устранением рисков в порядке убывания опасности для проекта И если первые два пункта более-менее вопросов не вызывают, то в последнем и заключена магия хорошего менеджмента. Как отреагировать на появление риска в уникальных условиях данного проекта? Как уменьшить риск, с которым ранее никогда не сталкивался? Как подкорректировать реакцию на риск, которая в прошлый раз оказалась неэффективной? Если бы все менеджеры всегда знали ответы на эти вопросы, количество проваленных проектов не превышало бы количество успешных, как это происходит сейчас. Однако есть и хорошие новости, которые заключаются в том, что существуют предложенные разными авторами наборы паттернов, проверенных опытом реакций менеджера на возникновение определённых рисков. Естественно, эти паттерны не могут подойти в 100% ситуаций, более того, они всегда потребуют определённой интерпретации в условиях конкретного проекта и конкретного риска. Однако такие паттерны способны дать определённое нулевое приближение, начальную рекомендацию, которая уже может быть пропущена менеджером через призму ситуации и превращена в готовое решение. Сегодня я приведу набор паттернов уменьшения рисков, предложенный Алистэром Коуберном в [1]: 1. Знания: Рассеивание тумана (Clear the Fog) Если вы не знаете риски и трудности проекта достаточно хорошо для того, чтобы разработать хороший план - попытайтесь выпустить хоть что-то, это даст вам понять в чём реальные трудности. Частные случаи: "Ранние и регулярные выпуски", "Прототип", "Микрокосм". 2. Знания: Ранние и регулярные выпуски (Early and Regular Delivery) Вы не знаете какие проблемы вам встретятся в процессе разработки - выпустите что-то как можно раньше и выясните то, чего не знаете. Выпускайте регулярно совершенствуясь каждый раз. 3. Знания: Прототип (Prototype) Вы не знаете как некотрые архитектурные решения себя поведут - разработайте отдельный испытательный прототип и понаблюдайте как он на самом деле работает. 4. Знания: Микрокосм (Microcosm) Вам нужно разработать реальный план, но вы никогда не занимались проектами такого рода - запустите 8-12 недельный "пилотный" этап и соберите данные о продуктивности и т.п. для вашего плана. 5. Командная работа: Целостное многообразие (Holistic Diversity) Разработка некоторого модуля требует разных умений, а люди имеют узкую специализацию - создайте команду из людей с разными умениями. 6. Продуктивность: Золотой рывок (Gold Rush) У вас нет времени ждать утверждённых требований - начните разработку немедленно, корректируйте её по последним требованиям еженедельно. 7. Владение: Один ответственный на продукт (Owner per Deliverable) Иногда над чем-то работает много людей, иногда никто - убедитесь что у каждого продукта (выпуска) есть ровно один ответственный. Частные случаи: "Владельцы функциональности и компонент", "Одна команда на задачу" 8. Владение: Ответственные за функциональность и компоненты (Function Owners / Component Owners) Если вы организовываете команду по компонентам, то страдает функциональность, и наоборот - убедитесь что за каждую функциональность и каждую компоненту кто-то отвечает. 9. Помехи: Кто-то всегда движется к цели (Someone Always Makes Progress) Помехи постоянно прерывают работу команды - убедитесь что кто-то движется к цели что бы не случилось. Частные случаи: "Одна команда на задачу", "Жертва", "Ежедневная забота" 10. Помехи: Одна команда на задачу (Team per Task) От команды требуется серьёзное отвлечение от основной задачи - пусть этим займётся часть команды, а основная команда продолжает идти к цели. 11. Помехи: Жертва (Sacrifice One Person) От команды требуется небольшое отвлечение от основной задачи - поручите это одному человеку. 12. Обучение: Ежедневная забота (Day Care) Ваши експерты тратят всё свое время на обучение новичков - выделите одного эксперта курировать всех новичков, остальные разрабатывают систему. В самой статье приводится детальное описание ситуаций с примерами и подробное объяснения механизма работы каждого паттерна, так что тем кто заинтересовался лучше ознакомиться со статьёй полностью.   Источники 1. Alistair Cockburn 'Project risk reduction patterns'

Posted by Vitalii Tsybulnyk on Saturday, August 29, 2009 5:18 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Разработка ПО как основанная на сотрудничестве игра

Когда в 1968 году на конференции НАТО впервые был введён термин “software engineering” для разработки ПО как одной из областей инженерии, эта классификация была скорее вызовом, стимулом для дальнейшей работы, чем основанной на реальном опыте моделью. Однако за неимением ничего лучшего она быстро прижилась, и на протяжении последующих 40 лет философы и методологи разработки ПО боролись с использованием этого подхода в основном по 4-м причинам: Такая классификация никак не отражает наиболее важные для успеха проекта вещи, такие как талант, мастерство, командное взаимодействие и коммуникация между людьми. Такой подход не соответствует историческим данным об успехах и провалах проектов, в частности противоречит более вероятному успеху проектов с менее строгими "церемониями" и с более "легковесным" с точки зрения правил и рамок процессом. После 40 лет использования разные люди и организации всё ещё трактуют термин и процесс "софтверной инженерии" совершенно по-разному. Ни термин, ни классификация не дают раельно эффективного направления работы в области разработки ПО, которое могло бы гарантированно (или хотябы вероятно) привести проект к успеху. Многие авторы предлагают свой собственный подход к этой проблеме. В этом посте я хочу поделиться моделью, предложенной Алистэром Коуберном [1]: Разработка ПО - это серия ресурсно-лимитированных, целенаправленных, основанных на сотрудничестве игр в изобретение и взаимодействие. Основной целью каждой игры является производство и развёртывание софтверной системы. По окончанию игры остаётся набор меток, которые помогут игрокам в следующей игре. Люди используют эти метки для напоминания, вдохновления и информирования друг друга во время следующего хода в этой игре, таким образом второстепенной целью игры является создание благоприятной ситуации для следующей игры. Основная и второстепенная цели конкурируют за ограниченные ресурсы. Такая модель действительно раскрывает все важные для успеха проекта проблемы: сотрудничество, коммуникации (а особенно их стоимость, доля и необходимое количество), индивидуальные таланты и умения, отношения между людьми-как-индивидуумами в парах и группах, ценность сохранения устоявшихся команд, уменьшающаяся отдача от детального моделирования и документирования [2], важность обучения и применения различных стратегий для различных обстоятельств. И хотя большинство словарей при определении термина 'игра' акцентируются на развлекательном аспекте (что и вызывает несогласие с игровой моделью Коуберна), смысл этого термина претерпел существенные изменения на протяжение последних десятилетий, так же как и отношение к удовольствию, получаемому участниками рабочего процесса от выполняемой ими работы. Именно необходимость получения этого удовольствия для успешной работы и приводит разработку ПО так близко к термину игры. Опуская детальную классификацию игр, обсудим лишь категорию, в которую попадает разработка ПО: это конечная (ограниченная достижением конкретной цели) игра, основанная на сотрудничестве. В этой же категории находится, например, альпинизм: конкретной целью является достижение вершины, а участники игры не конкурируют, а сотрудничают для достижения этой цели. После достижения цели как правило происходит оценка удовольствия, полученного от процесса, и анализ ошибок, результаты которого невероятно ценны для достижения последующих целей. Это как две капли воды похоже на разработку софта, только цель там своя - получение и развёртывание работоспособной системы. Второстепенная цель при этом точно та же: в процессе и по окончанию игры извлечь максимальную пользу и тем самым как можно лучше подготовиться к следующей игре. При этом большинство проектных команд ограничено во времени, деньгах и людях, так что полное достижение обеих целей врядлм возможно. Это и делает протекание каждой игры таким чувствительным к личностным характеристикам участников и (как следствие) абсолютно неповторимым.   Источники 1. Alistair Cockburn 'The end of software engineering and the start of economic-cooperative gaming' 2. Alistair Cockburn 'How many work products are needed in software development?'

Posted by Vitalii Tsybulnyk on Wednesday, August 26, 2009 2:06 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Инкрементная итерационная разработка

Для начала поговорим о понятиях:  Инкрементная (incremental) разработка - это стратегия планирования стадий проекта, при которой различные части системы разрабатываются в разное время, а затем интегрируются (в противоположность стратегии "большого взрыва", когда все части разрабатываются одновременно, а в самом конце разработки интегрируются). При инкрементной разработке вся система разбивается на отдельные компоненты или модули, разработка каждого из которых планируется и осуществляется отдельно во времени, с последующей интеграцией в систему по мере готовности. Итерационная (iterative) разработка - это стратегия планирования ревизий системы, во время которых система определённым образом дорабатывается или усовершенствуется (в противоположность стратегии, когда система планируется и создаётся сразу совершенной, идеальной). При итерационной разработке основным видом деятельности является усовершенствование, доработка существующей системы: не только производительности, качества кода и функциональных возможностей, но и требований, интерфейсов, технологий, архитектуры и алгоритмов. Отождествлять эти два подхода было бы такой же ошибкой, как и противопоставлять их друг другу. На самом деле, эти две стратегии абсолютно не противоречат, а наоборот, усиливают друг друга. Инкрементная разработка незаменима для больших систем, однако она сравнительно проста в планировании. Итерации сравнительно более сложно выделять и планировать, как следствие ими сложнее управлять (особенно для больших систем), однако например в условиях нечётких или изменчивых ребований они бесспорно необходимы. Таким образом, применение к сложной системе обоих подходов многократно усиливает каждый из них: разбивая всю систему на инкременты и применяя к каждому из них итерации, мы таким образом делаем процесс одновременно более управляемым и более гибким для переработок. Кроме того, самая рискованная и ответственная часть инкрементной стратегии - интеграция - перестаёт быть таковой как раз благодаря итерационному процессу.   Источники 1. Alistair Cockburn 'Using both incremental and iterative development'

Posted by Vitalii Tsybulnyk on Monday, August 24, 2009 2:11 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Какие бывают архитекторы и архитектуры

Мне кажется, что роль Архитектора - это пожалуй одна из самых значимых и одновременно самых неоднозначных ролей в процессе разработки ПО. Это связано с очевидной важностью, но тем не менее неоднозначностью самого понятия "архитектура". Согласно RUP архитектура - это "высший уровень концепта системы в её рабочем окружении. Архитектура программной системы (в определённый момент времени) - это её организация или структура наиболее значимых компонент, взаимодействующих через интерфейсы, а эти компоненты в свою очередь составлены из более мелких компонентов и интерфейсов." Однако Мартин Фаулер считает это определение абсолютно надуманным [1], т.к. по его мнению у программных систем нет "высшего концептуального уровня", пользователь имеет обсолютно другое видение концепции системы, чем разработчики, пользователя абсолютно не волнует "структура наиболее значимых компонент". По мнению Фаулера "архитектура - это высший уровень концепта, который сложился у разработчиков о системе в её рабочем окружении. При этом учитывается видение разработчиков уровня эксперта, и именно это делает компоненты такими значимыми - так сказали эксперты." Таким образом, более корректным определением могло бы быть “В наиболее успешных софтверных проектах разработчики-эксперты, работающие над проектом, имеют общее пронимание строения этой системы, которое называется ‘архитектура’. Это понимание включает в себя деление системы на компоненты и их взаимодействие между собой через интерфейсы. Эти компоненты обычно состоят из более мелких компонент, однако архитектура включает в себя только те компоненты и интерфейсы, которые поняты всеми разработчиками." Такое определение лучше, поскольку оно отражает социальную природу арихитектуры, т.к. она не столько зависит от ПО как такового, сколько от того, каков групповой консенсус по поводу этого ПО [1]. Существует и другой стиль определения архитектуры: “арихитектура - это набор решений об устройстве системы, которые должны быть приняты на ранних стадиях проекта”, однако Фаулер не соглашается и с этим, т.к. "архитектура - это набор решений, которые хотелось бы сделать правильно на ранних стадиях проекта, однако это не значит что они окажутся верными с большей вероятностью, чем любые другие". Тем более, что согласно такому определеню, например выбор языка программирования был бы частью архитектуры для большинства проектов, хотя это не так. Всё это демонстрирует сложности формулировки точного определения понятия архитектуры. Говоря проще, "архитектура - это всё наиболее важное в проекте, что бы это ни было" [1]. Так мы приходим к заключению, что раз архитектура - это важные вещи, то Архитектор - это человек, занимающийся наиболее важными для проекта вещами. И вот на этом этапе Фаулер выделяет два типа архитекторов [1]:  - Architectus Reloadus (по прообразу персонажа из фильма "Matrix Reloaded") - это человек, принимающий в проекте все важные решения. Он делает это потому, что принятие ключевых решений одним человеком повышает целостность системы, и возможно ещё потому, что он не считает остальных членов команды достаточно компетентными для принятия таких решений. Зачастую такие решения должны быть приняты вначале цикла разработки, чтобы у всех остальных был план, которому можно следовать.  - Architectus Oryzus (если кто-то знает латынь, помогите с переводом) - этот вид архитекторов осведомлён о том, что происходит в проекте, выявляя важные загвоздки и устраняя их до того как они превратятся в серьёзные проблемы. Наиболее важная часть работы таких архитекторов - это интенсивное сотрудничество: работа с разработчиками над кодом, работа с бизнес-аналитиками над техническим смыслом и последствиями реализаций требований и идей на нетехническом языке и т.п. Ценность архитектора этого типа "обратно пропорциональна количеству решений, которые он принимает" [1]. Не менее интересную крассификацию архитектур и архитекторов предлагает Люк Хохман [2]. Он разделяет софтверную систему на два измерения:  - tarchitecture (техтектура или “техническая архитектура”), за неё обычно отвечает традиционный архитектор или технический руководитель - tarchitect (техтектор)  - marketecture (маркетектура или “меркетинговая архитектура”), её определяет продукт-менеджер, бизнес-менеджер или програм-менежер - marketect (маркетектор). Техтектура преобладает, когда разработчики думают об устройстве системы. Маркетектура - это бизнес перспектива этого устройства. Хотя техтектура и маркетектура влияют друг на друга, маркетектура доминирует: маркетектурные вопросы - начиная от юзабилити, апгрейдабилити,  саппортабилити и заканчивая развёртываемостью и надёжнотью (т.н. нефунциональные требования) - меняются радикально от рынка к рынку и влияют на техтектуру более значительно, чем техтектурные вопросы о внутреннем устройстве системы влияют на её бизнес-ценность. Я бы даже усилил это утверждение: по-настоящему хороший продукт начинается тогда, когда маркетекрута полностью перестаёт подчиняться техтектуре, а техтектура в свою очередь действует исключительно в рамках предложенной маркетектуры.   Источники  1. Martin Fowler 'Who Needs an Architect?' 2. Luke Hohmann 'The Difference between Marketecture and Tarchitecture'

Posted by Vitalii Tsybulnyk on Saturday, August 22, 2009 7:21 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Методики успешных проектов: подрезаем хвост

Думаю, что методика "подрезания хвоста" (“trim the tail”) интуитивно используется многими менеджерами проектов, однако весьма полезно было бы ознакомиться с тем, как Алистэр Коуберн в своей статье [1] приводит довольно подробное описание и аргументацию эффективности этого подхода. Использование методики направлено на наиболее эффективное управление рисками и приоритетами в проекте путём правильной последовательности выполнения задач, что приводит к облегчению выбора между раннией поставкой менее функциональной версии продукта и поздней поставкой более полной версии. Согласно методике, стратегия работы над проектом состоит из двух основных стадий: 1. Как можно раньше определить наибольшие социальные и технические риски проекта (как правило, все и так это делают), разбить их на как можно более мелкие компоненты (задачи). Работать над этими "рискованными" задачами на как можно более ранней стадии проекта до перевода в статус "нерискованных". Таким образом происходит как можно более раннее накопление критических знаний о системе (рис.1). 2. Определить и расставить приоритеты самым ценным для бизнеса функциональным единицам проекта (как правило, все и так это делают) и работать над ними в порядке убывания приоритетности. Таким образом происходит максимально быстрое увеличение бизнес-ценности системы (рис.2). Рисунок 1: раннее накопление критических знаний о системе. Рисунок 2: быстрое увеличение бизнес-ценности системы. Перемещение менее приоритетных задач (например по повышению качества и усовершенствованию функциональности) в конец очереди выполнения приводит к тому, что в любой момент времени бизнес-ценность системы максимальна по отношению к затраченному времени. Кроме того, перемещение наименее рискованных и наименее ценных для бизнеса задачи в конец цикла разработки позволяет дать бизнесу выбор между раннией поставкой менее функциональной версии продукта (тем не менее содержащей наиболее ценную фунциональность) и поздней поставкой более полной версии (что в свою оченредь не влечёт больших технических или социальных рисков). Рисунок 3: отрезаем хвост. Это и состовляет наибольшую ценность подхода: спонсор в реальном времени получает безопасную с точки зрения рисков возможность "отрезать хвост" (рис.3): найти оптимальный для бизнеса балланс между временем выпуска системы и её фунциональной наполненностью.   Источники 1. Alistair Cockburn 'From Agile Development to the New Software Engineering'

Posted by Vitalii Tsybulnyk on Wednesday, August 19, 2009 5:30 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Антропология разработки ПО

В разработке ПО несколько абсолютно разных культур работают вместе. Это программисты, разработчики баз данных, дизайнеры пользовательского интерфейса, тестировщики, аналитики, менеджеры, спонсоры проекта, группа маркетинга и в конце концов конечные пользователи. Деление на группы происходит и в других измерениях: новички и эксперты, рациональные и интуиты и т.п. Внутри каждой такой группы пропагандируются свои ценности, которые могут вступать в противоречие с ценностями других групп, однако каждая культура имеет определённые формы защиты для своего выживания, т.к. групповые или культурные ценности как правило способствуют лучшему вкладу в дело проекта... Как правило, но не всегда. Обычной реакцией на обнаружение несоответствия ценностей является попытка изменить сами культуры. Например, убедить руководителя отменить все митинги и просто дать программистам работать над проектом "пока они всё не сделают", или попросить пользователей стать экспертами в ООП, или дизайнеров использовать формальные нотации... Группы пытаются изменить друг друга. Происходит это потому, что ещё никто и никогда не пытался создать некую карту групповых ценностей и выяснить:  - какие части групповых стратегий позволяют им успешно делать своё дело?  - какие ценности для них характеризуют успешность-неуспешность?  - что ещё влияет на успех каждой группы?  - какие ценности и культурные характеристики могут быть безопасно изменены?  - где проходит грань между гармонией и конфликтом культур?  - как выглядит полная карта суммарной системы ценностей всех участников? Результаты такой работы дали бы возможность: 1. Распознать все культуры, вовлечённые в проект, и их ценности. 2. Найти людей, способных работать по обе стороны разных культур и которые бы способствовать эффективной коммуникации культур и сглаживанию основных противоречий. 3. Информировать каждую из групп о целях и ценностях других групп, относиться к ним с должным вниманием и уважением и в то же время знать и использовать всё, что другая культура может им предложить. 4. Применить наработанные этнографические и антропологические техники для изучения каждой группы и обнаружения их сильных и слабых сторон. Коротко говоря, это дало бы возможность при организации работы над проектом использовать объективные факты вместо желаний и догадок, как это делается сейчас.   Источники 1. Alistair Cockburn 'What can OO programming learn from anthropology?'

Posted by Vitalii Tsybulnyk on Wednesday, August 19, 2009 4:04 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Рефакторим базу данных

Последние годы техника рефакторинга настолько прочно вошла в методологии процессов разработки ПО и инструментарий разработчиков, что всё чаще и чаще звучат утверждения о начале эры принципиально новых, эволюционных подходов к проектированию архитектуры. Пожалуй, одной из немногих областей, которая ещё прочно держит позиции предварительного проектирования, является структура базы данных. Действительно, изменение структуры базы данных по ходу жизненного цикла сопряжено с рядом существенных струдностей и затрат: это и миграция данных, и необходимость каскадного изменения кода приложений, использующих базу данных, и ряд других объективных трудностей. Однако, прогресс не стоит на месте, мыслители и идеологи рефакторинга и гибких методолий конечно же не мирятся с таким упущением. Наглядное тому подтверждение - некоторые книги и статьи Мартина Фаулера и его соратников. Одна из первых таких публикаций - это статья Фаулера 'Evolutionary Database Design', которая собственно и натолкнула меня на написание данного поста. Прежде чем говорить о применении техник рефакторинга по отношению к базам данных, нужно упомянуть некоторые ограничения, выход за рамки которых может существенно затруднить или даже сделать невозможными эти техники: 1. База данных исполюзуется в одном приложении или системе, это не интегрированная база данных для многих систем. 2. База данных не должна работать бесперебойно 24/7 Если данные условия соблюдены для вашего случая, можете смело рассчитывать применять к своей базе данных все те же подходы, которые уже успрешно применяете для всего остального кода проекта. Вот некоторые детали реализации рефакторинга применительно к базе даннных: 1. DBA и девелоперы должны очень тесно сотрудничать, т.к. рефакторинг базы данных с большой вероятностью влечёт изменения кода. Устраните все физические, психологические и бюрократические препятствия на пути их сотрудничества. Лично я всегда предпочитал DBA и девелопера в одном лице, котя конечно же это далеко не всегда целесообразно и возможно. 2. У каждого участника процесса есть своя копия базы данных для експериментов по нахождения оптимального рефакторинга. 3. Тестовая база данных - это не просто схема, она также содержит тестовые данные, близкие к реальным. Рефакторинг базы данных - это не только изменение схемы, он зачастую требует миграции и т.п. работы с данными. Чем больше данных содержит ваша тестовая база данных, тем более гладко пройдёт рефакторинг на продакшн базе. 4. Все изменения в базе данных по ходу работы над проектом - это рефакторинги, поэтому применяйте к ним те же шаги и правила, что применяете к обычному рефакторингу (см. Martin Fowler 'Refactoring: Improving the Design of Existing Code') 5. Автоматизируйте свой рефакторинг по окончанию работы над ним: сохраните скипт, производящий ваш рефактронг, с тем чтобы простым запуском этого скрипта вы могли выполнить рефакторинг на любой из копий базы данных, включая продакшн. 6. Сообщайте о изменнениях в базе всем разработчикам, лучше через автоматическую отправку е-мейла. 7. Выделяйте в своей системе явно выраженный слой доступа к данным, это позволит свести к минимуму последствия рефакторинга базы для остального кода (воспльзуйтесь одним из паттернов, описанных Фаулером в 'Patterns of Enterprise Application Architecture'). Ну и напоследок, хороший предварительный дизайн базы данных - это бесспорно очень хорошее начало для любого проекта. Однако последующие изменения неизбежны, и в нех нет абсолютно ничего страшного. Эволюционное изменение базы данных по ходу проекта не только уменьшит для вас затраты на предварительный дизнайн, но и избавит ваших разработчиков от необходимости подстраиваться под неудачный или устаревший дизайн базы данных. Следуйте приведённым выше рекомендациям и изменение базы данных превратиться для вас из страшилки для новичков в обыденную работу над доведением системы до идеала.

Posted by Vitalii Tsybulnyk on Tuesday, August 11, 2009 4:25 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Как правильно проводить Scrum (stand-up) митинги

Основой для данного поста послужила статья Jason'а Yip'а 'It's Not Just Standing Up: Patterns of Daily Stand-up Meetings', пропущенная через призму моего собственного опыта ежедневных Scrum-митингов в Microsoft. Вот перечень нескольких основных принципов, без следования которым ваш Scrum-митинг наверняка потеряет львиную долю эффективности: Цели:    - Поделиться обязательствами. Это самая важная цель ежедневного stand-up'а, более важная, чем поделиться прогрессом или состоянием задач.  - Обсудить статус, прогресс и планы с командой и наблюдателями. Обсуждение статуса наиболее всего отличает stand-up от любого другого вида статус-митингов, т.к. во время stand-up'а члены команды сообщают статус друг другу, а не своему менеджеру. Обсуждение статуса также даёт возможность команде быть в курсе всего, чем занимается команда каждый день.  - Выявить препятствия, чтобы команда могла предпринять шаги по их устранению. Хороший stand-up должен создавать ощущение поддержки, любой намёк на обвинение или осуждение быстро останавливает людей от оглашения своих проблем во время stand-up'а. Более того, оглашённые проблемы обязательно должны быть решены или поручены тем, кто их может решить.  - Установить направление и приоритеты.  - Тим-билдинг. Нельзя забывать, что основной фокус stand-up'а - это всё-таки не задачи, а люди, и stand-up призван решать именно человеческие проблемы и трудности. Место и время:  - Продолжительность ежедневных stand-up'ов - не более 15 минут, т.к. после 15 минут среднестатистический человек начинает терять состредоточенность. Недопустимо потакание некоторым любителям поболтать и их "рассказыванию историй". Также не нужно немедленно решать возникшие проблемы. Обсудите только вопросы, удовлетворяющие целям stand-up'а, все остальные вопросы обсудите после митинга или вынесите на отдельный митинг. Для того, чтобы митинг не затянулся, проводите его стоя, что также придаёт дополнительную энергетику.  - Динамичность и энергетика, обусловленные короткой продолжительностью, должны давать заряд бодрости на весь день. Кроме того, желательно, чтобы конец митинга был тем-то чётко обозначен, например характерной фразой, т.к. это (в противовес постепенному осознаванию, что сказать больше нечего) позволяет сохранить энергетику и динамику митинга.  - Проводите ежедневный stand-up в одном и том же месте в одно и то же время. Не ждите опаздывающих, даже если это менеджер или лидер, митинг проводится для всей команды а не для какой-то отделной персоны.  - Проводите stand-up в начале дня. Если в команде гибкий рабочий график, проводите митинг в самом начале времени, к которому собираются все. Помните, что stand-up задуман как психологическое начало рабочего дня. Участники:   - Все члены команды должны принимать участие в Scrum-митинге. Если кто-то не может учавствовать лично, он может поучавствовать по телефону или его статус должен огласить другой член команды.  - К Scrum-митингам, как и к любым другим, нужно готовиться. “Что я делал вчера?... Не помню уже... Что я делаю сегодня?... Посмотрим по ходу...” - такого быть не должно, все должны чётко знать свои 'Вчера', 'Проблемы' и 'Сегодня'. Управление:  - Члены команды не рапортуют лидеру. Основа ежедневных stand-up митингов заключается в самоорганизации, хороший stand-up самоуправляемый, он больше похож на кофе-брейк, чем на митинг.  - Ведущий у митинга должен быть, но это не обязательно один и тот же человек, ведущий может сменяться по кругу или например зависеть от дня недели. Не поощряйте взгляд говорящего на ведущего, т.к. это похоже на отчёт перед одним человеком, а не всей командой.  - Все знают, кто должен говорить первым, для этого не нужна команда ведущего. Заведите правило наподобие "Первым говорит тот, кто пришёл последним" или любое другое. К сожалению, многие менеджеры, особенно имеющие существенный опыт руководства до перехода к Scrum, подсознательно тяготеют к несоблюдению многих из приведенных принципов, тем самым существенно понижая эффективность Scrum-митингов. Однако ответственность за эффективные stand-up митинги (как и за всё в Scrum) несёт вся команда, поэтому все её участники должны приложить максимум усилий для соблюдения хотябы большей части перечисленных идей.

Posted by Vitalii Tsybulnyk on Sunday, August 9, 2009 9:04 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Как продавать свой программный продукт

Наверно мало кто из опытных разработчиков никогда не задумывался о создании собственного программного продукта. Уж очень соблазнительным кажется мысль иметь своё собственное детище, в работе над которым не нужно слушать назойливого заказчика и плодами работы над которым к тому же не нужно делиться ни с кем. Только вот мало кто всё-таки решается пойти на все трудности сопряжённые со стартапом, и ещё меньше кому удаётся все эти трудности успешно преодолеть. Эрик Синк (Eric Sink) - хороший пример такого разработчика, так как он к тому же делиться опытом собственного стартапа на страницах своего блога. Пожалуй самая большая сложность для хорошего программиста при организации стартапа - это маркетинг. Поэтому я поделюсь сегодня двумя статьями Синка, посвящёнными как раз этому вопросу:  - 'Marketing is not a Post-Processing Step' ('Не оставляйте маркетинг на потом')  - 'Closing the Gap' о том, как эффективно продавать свой программный продукт. Статья состоит из двух частей: Proactive sales и Responsive sales (в русском переводе нашёл только вторую часть). Первая статья (что вполне явствует из названия) призвана развенчать весьма распространенное заблуждение, что маркетинг начинается там, где заканчивается программирование. Хороший маркетинг так работать не может. Его нельзя оставлять напоследок. В качестве наиболее важного составляющего хорошего (т.е. раннего) маркетинга Синк называет позиционирование: Главная идея позиционирования заключается в том, чтобы продукт занял определенное место в сознании представителей целевой аудитории. Решающим фактором будет то, как они воспринимут ваш продукт. В сознании пользователя определённую позицию может занимать только один продукт. Обычно понятие позиции состоит из трех частей: Во-первых, оно почти всегда включает в себя эпитет в превосходной степени. Часто люди помнят только самые первые и лучшие продукты в своей категории. Занимать шестое место в каком-то сегменте рынка чаще всего значит не занимать никакого. Во-вторых, определение позиционирования должно указывать, к какому типу относится ваш продукт. Если такого указания нет, вас ждут большие проблемы: продукт не может занять место на рынке, если его нельзя сравнить с другими продуктами той же категории. И, наконец, нужно точно описывать, какую группу потребителей вы хотите заинтересовать. Если ваш продукт уже занял какое-то место на рынке, лучше удостовериться, что вы правильно его оцениваете. Нравится вам это или нет, но это - отправная точка всей работы. Бывают ситуации, когда существующая позиция продукта мешает компании выполнить задуманное и занять другую позицию. Если вы просто начнете широко вещать о новом месте, которое, якобы, знанимает ваш продукт, рынок не пойдет навстречу, потому что вы перестали соответствовать образу, сложившемуся в умах потребителей. Как правило, если такая позиция действительно существует, то она уже кем-то занята. В этом случае, можно выбирать из двух возможных решений: выжить конкурента или найти другой вариант позиционирования. Маркетинг нельзя откладывать напоследок как раз потому, что вам надо сделать свой продукт таким, каким требуется для данного конкретного позиционирования. Если приложение не обладает функциональностью, которую ожидают пользователи от такого типа продукта, то вы, скорее всего, никогда не сможете закрепиться в выбранном сегменте рынка. Маркетинг не сводится к тому, чтобы прокричать на весь мир о своем продукте. Маркетинг - это еще и понимание, каким должен быть продукт. Вы должны с самого начала решить, какой функциональностью он должен обладать, чтобы занять выбранный вами сегмент рынка. Вторая статья рассказывает о разрыве, существующем между вашим продуктом и вашим потенциальным клиентом, и о том, как этот разрыв ликвидировать: Разрыв представляет собой расстояние, отделяющее потенциального клиента от вашего продукта. Пока оно существует, у клиента нет соответствующего программного обеспечения, а у вас - денег. Чтобы покупка состоялась, это расстояние необходимо преодолеть. До тех пор оно олицетворяет всевозможные проблемы и препятствия, которые мешают клиенту сделать покупку. Собственно говоря, у вас есть всего две возможности: "Сдвинуть" продукт к клиенту; "Сдвинуть" клиента к продукту. Этим двум способам и посвящены две части статьи. Первая часть посвящена активным продажам, во главе котоых стоит sales guy (распростанитель). Как бы многих из нас ни раздражали эти ребята, нужно признать, что некоторые бизнесы просто не могут без них существовать. Поэтому всякий, кто задумывается о стартапе, должен "учить мат. часть" и как минимум знать, что могут распространители и как этим пользоваться: Стереотипы распространителей могут слегка варьировать, но есть одно абсолютно необходимое требование: хороший распространитель - это некто, кто мотивирован только деньгами. Одна из самых опасных ошибок, допускаемых при найме распространителей -  это нанимать распространителей, которых волнует что-то ещё. Однако, я думаю большинству разработчиков, подумывающих о стартапе, приятно будет услышать, что подход "без распространителей" тоже имеет право на жизнь, более того, Синк называет его предпочтительным для большинства стартапов: Двигать потребителя к продукту очень трудно, особенно для маленькой компании. Все эти усилия лучше потратить на другую сторону разрыва: улучшайте свой продукт. Движение вашего продукта к потребителю намного проще. Прислушивайтесь к нему и давайте ему то, что он хочет. Держите своих клиентов в состоянии удовлетворённости и они расскажут своим друзьям какой вы замечательный. Фокусирование ваших усилий на продукте - это подход с двумя замечательными выгодами: он целиком в области вашей компетенции, т.к. вы знаете как сделать ваш продукт лучше, и когда вы делаете его лучше для одного потеребителя, вы также улучшаете его для других. Собственно, этому и посвящена вторая часть статьи, озаглавленная "Пассивные продажи": При пассивных продажах инициатива находится в руках клиента. Он устанавливает контакт с вашей компанией, только если сам того желает. Он узнает о вашем продукте от друзей или читая блоги. Изучает все, что может найти, о вашей компании и продукте. Связывается с вами и задает вопросы. Принимает решение сам, причем тогда, когда ему и его компании будет удобно. В конце концов, передает вам деньги и получает взамен продукт. Понимаю, идея пассивных продаж может поначалу вызывать некоторые опасения. Это все равно, что доверить важный проект плохо знакомому человеку, которого мы даже никогда и не видели. Но за риском следует награда. Дело в том, что клиенты любят, когда им доверяют. Им нравится принимать решения самостоятельно, без натиска торговых агентов. Им хочется взять инициативу в свои руки. Именно поэтому пассивные продажи так хорошо работают. Единственное условие: мы должны поддерживать общение с клиентом и своевременно отвечать на его запросы. Да, мы отдаем ему инициативу, но и на нашу долю приходится немало работы. Чтобы добиться успеха в пассивных продажах, Синк призывает помнить о семи важных вещах: 1. А знают ли потенциальные клиенты о вашем продукте? Если люди никогда не слышали о вашем продукте, то они никогда его и не купят. Осторожнее с рекламой. Можно потратить кучу денег и даже не понять, на что же они ушли. Я не говорю, что маленькие компании должны отказаться от рекламы. Просто делать это нужно осторожно. Участвуйте в выставках. Работайте "в открытую". Конечно, традиционные виды маркетинговых коммуникаций необходимы, но сейчас в маркетинге есть свои новшества. Учитывая повсеместную доступность интернета, лучше всего привлекать внимание к своему продукту, разрабатывая его "в открытую". Используйте веблоги и дискуссионные форумы, разрешайте людям "попробовать" ваш продукт, скачав демо-версию. Пусть клиенты наблюдают за процессом создания продукта, задают вам вопросы, обсуждают интересующие их возможности продукта. Представьте себя шеф-поваром китайского ресторана, который поджаривает на огромной сковородке креветки с овощами, пока клиент, сделавший заказ, наблюдает за процессом готовки. 2. А нужен ли ваш продукт пользователям? Прошу прощения за еще одну банальность, но факт остается фактом: если вы пытаетесь продать людям то, что им не нужно, "разрыв" между клиентом и продуктом будет огромным. Определитесь с позиционированием. Выберите конкурентов. Работайте "в открытую". 3. Могут ли пользователи позволить себе ваш продукт? Цена тоже влияет на величину "разрыва" между клиентом и продуктом. Некоторые выбирают программное обеспечение точно так же, как я покупаю обувь. Покупать дорогой товар удобно тем, у кого мало времени на скрупулезные исследования рынка. Высокая цена привлечет тех, кому нужен престиж или безупречное качество продукта. Но и у невысокой цены есть свои преимущества. Дело в том, что большинство ваших потенциальных клиентов ограничены бюджетом. Если цена продукта намного превышает бюджет, то "разрыв" будет просто непреодолимым. 4. Выложите на сайт демо-версию. Убедитесь, что её легко найти. Версия должна быть полнофункциональной. Позвольте пользователю сохранить анонимность. 5. Отвечайте на вопросы. 6. Отведите специальное место для общения пользователей. 7. Сделайте процесс покупки через веб удобным и простым. Обходитесь без регистраций. Не нужно "корзины". Отдавайте продукт сразу. И на последок ещё пару слов от Этика о том, почему это всё работает: Уверен, что не все согласятся с моими советами. Многие опасаются доверять пользователям. Если вы считаете, что я неправ, то скажите, пожалуйста, разве вы не хотели бы, чтобы продавцы относились к вам именно так, как я описал в этой статье? А если да, так почему бы вам не предоставить вашим клиентам такой же уровень обслуживания?

Categories: Books & Articles
Posted by Vitalii Tsybulnyk on Monday, August 3, 2009 6:16 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Новые методологии программирования Мартина Фаулера

Сегодняшний пост пожалуй будет последним из короткого цикла о гибких (agile) методологиях. Сегодня у нас в гостях снова Martin Fowler (Мартин Фаулер), несдвигаемая глыба в области современного проектирования и архитектуры программных продуктов, со своей статьёй 'The New Methodology' ("Новые методологии программирования"). Статья является великолепным обзором истории и нынешного состояния мирового Agile течения (или точнее сказать потока). Первая часть статьи приводит предпосылки возникновения Agile: Привлекательность новых методологий для многих заключается в отсутствии бюрократизма, присущего монументальным методологиям. Новые методологии представляют собой попытку достичь необходимого компромисса между слишком перегруженным процессом разработки и полным его отсутствием. Иначе говоря, объема процесса в них как раз достаточно, чтобы получить разумную отдачу. При строительстве моста на работы по проектированию уходит около 10% от всей стоимости работ. Остальное - затраты на конструирование. В программных разработках время, которое тратится на кодирование намного меньше. Отсюда вопрос о сущности проектирования при разработке программных продуктов и его отличиях от проектирования в других областях инженерной деятельности. Каждый раз, когда я сталкиваюсь с проектом, в котором наблюдаются проблемы, я слышу одно и то же. Разработчики приходят и говорят: "Все проблемы из-за того, что заказчик постоянно меняет требования". В этой ситуации меня удивляет только одно - почему все этому удивляются. При разработке программных бизнес-приложений требования должны изменяться, это нормально. Вопрос только в том, что можно сделать по этому поводу. Оценить длительность процесса разработки ПО тяжело по нескольким причинам. Во-первых, создание программных продуктов представляет собой работу по проектированию, которую трудно планировать и оценивать. Во-вторых, быстро меняются исходные материалы. В-третьих, очень многое зависит от конкретных людей, которые выполняют работу, а людей всегда сложно прогнозировать и подходить к ним с какими бы то ни было мерками. Это приводит к довольно ироническому умозаключению: все заказчики полагают, что требования можно менять. В конце концов, в слове "software" присутствует слово soft. Итак, требования не просто могут меняться - они должны меняться. Нужно положить много сил и энергии, чтобы заставить заказчика четко зафиксировать свои требования. Сделать это еще сложнее, если заказчики когда-то сами баловались разработкой ПО - тогда они знают, что изменить программу несложно. Впрочем, даже если вам удалось получить четкий список требований, все равно вы обречены. В современной экономике ценность тех или иных свойств программных продуктов меняется слишком быстро. То, что является достаточным набором требований сегодня, оказывается устаревшим уже через полгода. Даже если заказчики могут предоставить стабильный список требований, мир бизнеса от этого не замрет. А ведь многие изменения в мире бизнеса совершенно непредсказуемы (тот кто скажет, что я не прав, либо лжет, либо уже заработал миллион, играя на бирже). Далее Фаулер переходит к некоторым деталям и сложностям построения или перехда на гибкий процесс:   Одна из серьезных ошибок - делать вид, что вы используете предсказуемый процесс, в то время как вам это не удается. Разработчики методологий плохо определяют граничные условия, то есть, те ситуации, в которых методология из годной переходит в разряд негодной. Большинство методологов хотят, чтобы их разработками пользовалось как можно больше людей, при этом они не осознают граничные условия и не информируют о них пользователей. В результате этого методология нередко используется в неподходящих условиях, например, предсказуемую методологию могут использовать в непредсказуемой ситуации. Да, искушение велико. Предсказуемость - очень ценное свойство. Однако если вы будете считать, что можете прогнозировать события, в то время как уже утратили способность это делать, то непременно окажитесь в ситуации, когда план работ создан заранее, а момент, когда он перестает соответствовать действительному положению вещей, уже упущен. И вот, вы видите, как план и реальность медленно расходятся в противоположных направлениях. Конечно, можно довольно долго создавать видимость того, что план все еще выполняет свою функцию. Но в какой-то момент это расхождение становится настолько серьезным, что план просто разваливается. Как правило, событие это весьма болезненное. Контракт с фиксированной стоимостью предполагает неизменность требований, а значит, использование предсказуемого процесса. Если использовать адаптивный процесс при нестабильных требованиях, обычная установка на фиксированную оплату уже не срабатывает. Попытка втиснуть адаптивный процесс в рамки фиксированной оплаты приводит к весьма неприятным конфликтам. При этом самое неприятное то, что заказчик пострадает ничуть не меньше компании-разработчика. В конце концов, заказчику не понадобился бы программный продукт, если бы того не требовал бизнес. Если он не получит этот программный продукт, бизнес пострадает. Итак, даже если заказчик не заплатит компании разработчику ничего, он все равно несет убытки. Более того, он теряет даже больше, чем если бы заплатил за готовую систему (зачем бы заказчику платить за нее деньги большие, нежели ее коммерческая стоимость?) Осуществлять адаптивный процесс на деле - непростая задача. В частности, для этого нужна очень хорошая команда разработчиков. При этом необходимо, чтобы команда не просто состояла из специалистов высокой пробы, но и умела слаженно работать. Здесь наблюдается интересная взаимосвязь: для адаптивного процесса нужна сильная команда разработчиков, но и большинство хороших специалистов тоже предпочитают адаптивный процесс. Другая ключевая идея заключается в том, что разработчики должны иметь возможность принимать все технические решения. Наибольшего выражения это достигает в ХР, где только разработчики могут устанавливать, сколько времени должно уйти на ту или иную работу. Многие руководители воспринимают такое управление техническим процессом как нечто совершенно невероятное. Адаптивный процесс требует равного разделения ответственности за осуществление проекта между разработчиками и руководством. Обратите внимание, я сказал "равного". Руководство продолжает играть свою роль, однако при этом отдает должное мнению разработчиков. Нет ничего хуже для разработчика, чем видеть, как плоды его кропотливого труда идут в мусорную корзину. Поэтому так важно знать, что у вас есть хорошие консультанты, которые могут постоянно общаться с разработчиками и обладают достаточными знаниями в своей области, чтобы разработчики могли на них положиться. Далее в статье приводится замечательный пересказ истории возникновения различных направлений Agile (XP, Scrum, Crystal, Lean, RUP) и их объединения в единый термин Agile. Статья непременно должна быть прочитана теми, кто работал, работает или собирается работать согласно Agile.

Posted by Vitalii Tsybulnyk on Sunday, August 2, 2009 5:26 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Динозавров - на пенсию!

Сегодня я поделюсь замечательной статьёй Джима Хайсмита (Jim Highsmith) "Устаревшие методологии - на пенсию!" ('Retiring Lifecycle Dinosaurs'), продолжающей серию постов о гибких (agile) методолоиях. Как и большинство статей по agile, статья строится на том факте, что методологии разработки программного обеспечения могут и должны быть не менее изменчивыми, чем бизнес требования, технологии и сами люди: ... темп развития технологий и бизнеса все убыстряется, и статические способы управления становятся непригодными. Старый мир был миром оптимизации, где правили эффективность, предсказуемость и контроль. Новый мир - это мир адаптации, в котором главное место отводится изменениям, импровизации и новым идеям. Такая дихотомия - оптимизация против адаптации - позволяет нам ясно представить себе будущее управления программными разработками. Автор приводит основы разработанной им адаптивной методологии ASD (Adaptive Software Development), которая позволяет изменять многие параметры процесса прямо по ходу проекта, адаптируясь к новым условиям и обучаясь на ошибках и недостатках: В ASD обычный статический жизненный цикл Plan-Design-Build (Планирование - Проектирование - Конструирование) заменен на динамичный - Speculate-Collaborate-Learn (Обдумывание - Взаимодействие - Обучение). Этот цикл ставит своей целью непрерывное обучение. Он связан с постоянными изменениями, повторными оценками, попытками предугадать неизвестное на текущий момент будущее проекта и требует тесного взаимодействия между разработчиками, тестировщиками и заказчиками. (Обратите внимание, что весь этот цикл не всегда представляет собой правильный круг. Даже при итеративном процессе можно иногда отклоняться в сторону, чтобы изучить неисследованные до сих пор области). Методология ASD построена на концептуальной базе теории сложных адаптивных систем. Она рассчитана на использование в экстремальных проектах, в которых превалируют быстрый темп разработок, непредсказуемость и частые изменения. Есть проекты, которые не могут считаться экстремальными, однако для всех остальных ASD подходит гораздо лучше, чем любой традиционный подход к разработке ПО. Такой подход меняет традиционную последовательность действий и приоритеты при выполнении проекта, ставя во главу угла обучение: Так, например, постмортемы (переводчик использовал это слово, я бы подобрал более литературный вариант вроде "разбор полётов") проекта очень просты по сути. Они служат исключительно для того, чтобы определить, что прошло хорошо, где были сбои, и, наконец, какие изменения необходимо произвести. Как ни странно, многие организации не делают постмортемы, поскольку подобный обзор проделанной работы непременно превращается у них в политические игры и взаимные обвинения. Очень часто, вместо того, чтобы спросить себя "чему нам надо научиться?" мы начинаем искать ответ на вопрос "кто в этом всем виноват?". Запомните, чтобы ваша организация стала адаптивной и гибкой, ей нужно в первую очередь стать организацией, где умеют и любят обучаться. Это и радикально преобразуют весь стиль управления:  Команды разработчиков должны взаимодействовать при решении технических проблем и при определении требований к системе. Им необходимо улучшать свою способность принимать совместные решения. Руководству, кстати, пора передать командам больше прав для принятия решений, так как постоянные изменения (и жесткий график работ) совершенно исключают традиционный стиль управления - Command - Control (Приказ - Контроль). При этом руководителей больше должно беспокоить то, как добиться наиболее эффективного взаимодействия и обеспечить согласованность выполняемых работ, нежели вопросы проектирования, тестирования и кодирования. Как мы уже говорили, сегодня для многих проектов (например, для тех, которые разрабатывают физически удаленные друг от друга команды или постоянно меняющиеся партнеры) наибольшую важность имеет то, как люди взаимодействуют между собой, и как они справляются с неизбежно возникающей взаимозависимостью. Для небольших команд, где все разработчики работают в непосредственной близости друг от друга, тесная взаимосвязь и согласованность работ может быть достигнута неформальными методами. Все можно решить во время беседы в коридоре или порисовав немного у доски. В больших проектах все не так просто. Вполне очевидно, что далеко не каждому понравится такой метод. Многие руководители, привыкшие к традиционным методам, при компонентном подходе почувствуют, что могут частично утерять контроль и влияние на процесс. В таком случае, им лучше пересмотреть свои идеи и соображения относительно прогресса проекта. Изложенный подход очень органично перекликается с подходами Мартина Фаулера к необходимости постоянного рефакторинга: В итеративном жизненном цикле "переделка" продукта занимает не меньше места, чем его "создание". На производстве все обстоит по-другому. Там специальные программы, следящие за качеством работы станков, помогают избежать "брака" (результата ошибки в процессе изготовления какой-либо вещи) и последующей его переделки. Однако в области программных (и прочих интеллектуальных) разработок дело обстоит несколько по-иному, чем на конвейере, где бездушный автомат каждые несколько секунд штампует одинаковые штуковины. Кстати, весьма вероятно, что сама штуковина была спроектирована и разработана с применением итеративного процесса. Компоненты же, как правило, претерпевают изменения на протяжении нескольких итераций. Это происходит из-за того, что заказчики сообщают разработчикам свои комментарии относительно продукта по мере его развития. Примечательно аргументируется необходимость жёстких временных рамок для успешного протекания процесса: ... говоря о жестких временных рамках, мы должны иметь в виду не столько время и сроки, сколько принятие сложных компромиссных решений. Когда тебя окружают постоянные изменения, нужно периодически задействовать некий фактор, который будет заставлять доводить начатое до конца. Кроме того, существование временных рамок заставляет команду разработчиков и клиентов постоянно пересматривать основные показатели проекта: его границы, расписание работ и поставок очередных версий, ресурсы, дефекты и т.д. Те команды, которые не могут (или не хотят) принимать быстрые решения и делать выбор, никогда не добьются успеха в экстремальных условиях. На закуску пару весьма красивых фраз из статьи, призванных убедить всех в необходимости перехода к новым методикам работы:  "Оптимизирующие" культуры видят мир в черно-белом свете. "Адаптивные" культуры, в отличие от них, признают наличие серого. Они понимают, что планирование эфемерно, а контроль практически невозможен. "Адаптивные" культуры осознают, что успеха можно достичь, лишь испробовав несколько различных альтернативных вариантов, учась как на успехах, так и на ошибках. Они знают, что изучать новое часто не менее важно, чем использовать в работе давно привычное. ... разработка ПО - вовсе не механический, а органичный, нелинейный и недетерминированный процесс. Нужно изменить базовые принципы, на которых организации строят свою работу при решении сложных проблем, а также начать применять новые, связанные с ними, практики. Перейти из разряда оптимизирующих культур в разряд адаптивных означает сделать шаг в будущее, а не прозябать в прошлом.

Posted by Vitalii Tsybulnyk on Friday, July 24, 2009 5:22 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Каждой методологии - свое время

Сколько себя помню - всегда руководствовался принципом Алистэра Коуберна (Alistair Cockburn) "Каждому проекту своя методология" ( 'Methodology per project'). Неудивительно, что "продолжение" этого принципа в виде статьи "Каждой методологии - свое время" ('Just-in-time methodology construction') вызвало у меня немалый интерес. Русский перевод названия на мой взгляд немного неточен, я бы перевёл как "Построение методологии по ходу проекта", однако существующий перевод весма оправдан своей созвучностью со статьёй-предшественницей. Данная статья базируется на ещё одной известнейшей статье Алистера - "Люди как наиболее важные компоненты процесса разработки ПО" ('Characterizing people as non-linear, first-order components in software development'), о которой я уже писал Идея статьи проста, очень логична, и в то же время революционна: Коль скоро мы осознаем, что каждый проект заслуживает своей собственной методологии, то становится понятно, что любое изначальное предположение о ней является всего лишь догадкой. Это утверждение закладывает основу всем так называемым динамическим методологиям, т.е. методологиям, динамически изменяющимся по ходу проекта. Таким образом, поиск наиболее эффективной методологии сводится к поиску ответа на вопрос "как нам с течением времени трансформировать эту догадку в нечто действительно полезное для проекта". Ответ на этот вопрос, конечно же, существует не один. Коуберн выделяет следующие ключевые моменты:  - Разработка ведется инкрементным методом. Насколько я могу судить, это единственное необходимое методологическое условие.  - После каждого инкремента проводите общее собрание, на котором задавайте один-единственный вопрос: "Что мы могли бы делать лучше?"  - Берите за основу сильные стороны человеческой натуры Результатом работы Коуберна стала разработка целого семейства методологий Crystal. Метологии внутри этого семейства различаются по 3-м критериям: люди, критичность, приоритетность. Все методологии Crystal различаются по цвету, причем каждый цвет предназначен для определенных проектов и имеет свои собственные характеристики: Clear ("Прозрачная") для самых легких и небольших проектов, затем Yellow ("Желтая"), Orange ("Оранжевая"), Red ("Красная") и т.д., для больших команд, использующих более тяжелые методологии. Методология каждого цвета обладает своими собственными правилами и базовыми элементами. При этом каждая легка настолько, насколько это хорошо и правильно для данного типа проектов. Таким образом, изложенные в статье подходы - это не только одна из первых техник динамического (или своевременного) создания методологии, позволяющая выработать и "настроить" необходимые соглашения и стандарты по работе над проектом, эффективные методы общения и влиять на боевой дух команды, быстро избавляясь от малоэффективных методов работы, и опробовать новые до тех пор, пока не будет выработан некий приемлемый вариант. Кроме того изложенные в статье идеи позволяют создать целую "семью" или спектр методологий, которые бы имели в основе одни и те же базовые принципы, и которые можно было бы точно так же "настраивать" по ходу проекта.

Posted by Vitalii Tsybulnyk on Thursday, July 23, 2009 6:40 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Проектирования больше нет?

Martin Fowler (Мартин Фаулер) бесспорно является одним из самых уважаемых авторов в области современного проектирования и архитектуры программных продуктов. Его бестселлеры 'Refactoring: Improving the Design of Existing Code' и 'Patterns of Enterprise Application Architecture' - это, пожалуй, наиболее ценные книги, прочитанные мною за всю мою профессиональную жизнь. Недавно мне в руки попала замечательная статья Мартина с броским названием 'Is Design Dead?' (в русском переводе "Проектирования больше нет?"), о которой сегодня и пойдёт речь. Основная идея статьи - обсудить изменения в подходах к проектированию программных систем в связи с переходом к гибким (Agile) методологиям. Провокационное название статьи отражает тот факт, что многие Agile методологи (в первую очередь XP) преподносят дизайн системы как нечто возникающее эволюционно, в процессе непосредственного кодирования: Методология XP бросила вызов многим устоявшимся представлениям о разработке программного обеспечения. Пожалуй, наиболее противоречивой идеей является отказ от предварительного проектирования в пользу более эволюционного подхода. Для приверженцев новой методологии, это отказ от техник проектирования (например, UML), их принципов и паттернов. Незачем беспокоиться о проектировании, считают они. Достаточно внимательно "вслушиваться" в свой код, и проектирование образуется само собой. Фаулер, как выдающийся специалист в области проектирования, конечно же не соглашается с таким утверждением: В большинстве случаев, эволюционное проектирование - это нечто ужасное. В конце концов, все равно вместо дизайна системы вы получаете просто набор из специфических решений, каждое из которых затрудняет дальнейшие изменения в программном коде. Часто это вообще нельзя считать дизайном (и, уж конечно, такой дизайн никак нельзя назвать хорошим). Как говорит Кент, дизайн существует для того, чтобы дать возможность оперативно вносить в систему любые изменения. Если дизайн плох, то такая возможность исчезает. В результате вы будете иметь дело с энтропией программного продукта, и со временем и без того плохой дизайн системы станет еще хуже. Теперь вам будет не только сложнее вносить в систему изменения, но и отыскивать и исправлять ошибки, которые начинают множиться с катастрофической быстротой. Все это - кошмар разработок в стиле "code and fix", когда с течением времени исправление ошибок обходится все дороже и дороже. Однако одновременно являясь ярым приверженцем Agile и автором "библии" рефакторинга, Фаулер признаёт и рекламирует их эффективность: В методологии XP имеется много спорных моментов. Одним из ключевых таких моментов является то, что она базируется на эволюционном, а не предварительном проектировании. В основе этого утверждения лежит кривая стоимости изменений в программном продукте. XP строится на предположении, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой, оно же в ней и используется. Это еще раз подчеркивает тесную взаимосвязь между практиками ХР: нельзя использовать те части методологии, которые предполагают существование сглаживания, не используя те практики, которые это сглаживание осуществляют. У практик, с помощью которых осуществляется сглаживание, есть множество составляющих. В основе всех их лежит Тестирование и Непрерывная интеграция. Именно надежность кода, которую обеспечивает тестирование, делает возможным все остальное в этой методологии. Подобный эффект имеет и рефакторинг. В статье Фаулер пытается найти компромис, балланс между традиционными (и бесспорно необходимыми) методиками проектирования с одной стороны и Agile с другой: Джим Хайсмит ... использует аналогию с обычными весами. На одной чаше лежит предварительное проектирование, на другой - рефакторинг. В более традиционных подходах к разработке ПО перевешивает предварительное проектирование, так как предполагается, что передумать вы не можете. Если же стоимость изменений снизится, то часть проектирования можно делать и на более поздних стадиях работы, в виде рефакторинга. Это вовсе не означает отказа от предварительного проектирования. Однако теперь можно говорить о существовании баланса между двумя подходами к проектированию, из которых можно выбрать наиболее подходящий. Все эти основополагающие практики (непрерывная интеграция, тестирование и рефакторинг) создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно. Впрочем, мы еще не выяснили, где же у этих весов точка равновесия. Лично я уверен, что не смотря на поверхностное впечатление, методология ХР - это не просто тестирование, кодирование и рефакторинг. В ней найдется место и для предварительного проектирования. Частично оно производится еще до написания первой строчки кода, но большая его часть приходится на то время, которое предшествует реализации конкретной задачи в течение итерации. Впрочем, такая ситуация представляет собой новое соотношение сил между предварительным проектированием и рефакторингом. Собственно, вся статья и посвящена нахожденю этого компромисса. Показывается полезность и органичность предварительного проектирования в XP, преимущества и критерии простого дизайна перед сложным при условии следования всем остальным практикам XP, показывается эффективное сосуществование принципа YAGNI ("You Aren't Going to Need It" - "Это вам не понадобится") и рефакторинга, применимость и ценность паттернов проектирования и даже UML в XP. Пожалуй я воздержусь от приведения здесь заготовленных мною цитат из статьи, а закончу пост настоятельной рекомендацией причитать эту статью. Она как никакая иная ценна для опытных разработчиков, архитекторов и менеджеров, переходящих на Agile методологии и имеющих какие-то сомнения по применимости своих знаний и умений в новых условиях. Статья не мене полезна и тем, кто имеет большой опыть например в XP, но не имеющих базисных знаний и умений в предварительном проектировании. И пожалуй наиболее полезна статья тем, чьи знания, умения и опыт равноценны в обеих сферах, т.к. изложенные концепции позволят наиболее эффективно и гармонично использовать и сочетать все эти бесценные умения в вашей работе.

Posted by Vitalii Tsybulnyk on Wednesday, July 22, 2009 7:06 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Люди как наиболее важные компоненты процесса разработки ПО

Alistair Cockburn - это один из моих любимейших авторов в области управления процессом разработки программного обеспечения, а его статья "Characterizing people as non-linear, first-order components in software development" - несомненная жемчужина в сокровищнице мирового достояния по этому вопросу (русский перевод статьи доступен здесь). Автор, эксперт в области методологий разработки ПО, более 20 лет посвятивший изучению этого вопроса, пришёл к выводу, что на пути любой методологии стоит 2 основных проблемы: Людям, занятым в проекте, как правило совершенно неинтересно изучать новую методику. Они вполне могут обойтись и без методологов, и при этом успешно создавать программное обеспечение. Проанализировав около сорока проектов из своей практики, автор сделал следующие важные выводы: Практически любую методологию можно с успехом применять в каком-нибудь проекте. Любая методология может привести к провалу проекта. Тяжеловесные методологии тоже могут успешно применяться в работе. Облегченные методологии чаще приводят к успеху, и, что более важно, разработчики сами говорят, что успех проекта был обеспечен именно методологией. Я не нашел ни одной теории, которая объяснила бы, почему облегченные методологии (те, в которых мало места уделяется всяческим формальностям), чаще приводят к успешному завершению проекта, нежели тяжелые методологии, где формальности играют очень большую роль. И тут я наконец-то понял, что прямо перед нами всегда находится нечто, чего мы не замечаем: люди. Именно человеческие качества обеспечивают успех тому или иному проекту, именно они являются фактором первостепенной важности, основываясь на котором надо строить прогнозы о проекте. Теперь я рассматриваю все в обратном порядке - сначала люди, а потом методология, как второстепенный показатель. Какие же человеческие качества делают людей одновременно и столь важной, и столь непредсказуемой компонентой процесса разработки? Автор выделяет следующие: Человек - существо, которому необходимо общение. Причем общаться он предпочитает в режиме непосредственного диалога, лично, по типу "вопрос-ответ". Человеку трудно постоянно работать сверхурочно. Человек - существо изменчивое, он меняется в зависимости и от времени, и от пространства. Как правило, у человека есть чувство гражданского долга, он может хорошо ориентироваться в ситуации, брать инициативу в свои руки и делать "все, что необходимо" для того, чтобы проект завершился успешно. Человеку нужно время, как на размышление, так и на общение. Человек хорошо работает, опираясь на примеры. Человек предпочитает скорее потерпеть неудачу из-за своего консерватизма, нежели рискнуть, но сделать что-то необычным образом; ему больше нравиться изобретать, а не находить готовые решения, он может одновременно держать в голове совсем немного сведений, он делает ошибки и с трудом меняет привычки. Отдельная личность может легко возобладать над проектом. Способность человека выполнять те или иные задания в большей степени определяется его личными качествами. Когда я провожу опрос по какому-нибудь проекту, я всегда спрашиваю людей, что, по их мнению, привело к конечному успеху работы. Чаще всего я получаю один и тот же ответ: "В ключевой момент разработки несколько человек взяли на себя инициативу и сделали все от них зависящее, чтобы выполнить проект". Приведу ещё парочку важных на мой взгляд заключений, изложенных автором в статье:   - Я прихожу к заключению, что большинство проектов вполне можно вести, руководствуясь (верными) не очень точными описаниями: не очень точную документацию по проекту легче читать, приводить в порядок и обсуждать. Архитектуру системы, изображенную с невысокой степенью точности, легче запомнить; в таблицах с не очень точно описанными требованиями легче расставлять приоритеты и легче оценивать масштабы сделанной работы на ранних стадиях проекта. Выполненная не очень точно проектная документация лучше передает "идею" проекта, после чего читатель может начать "ориентироваться в ситуации".  - Вариации поведения культур методологу учитывать еще труднее, чем вариации каждодневного поведения отдельных индивидуумов. На сегодняшний день я не знаю ни одной методологии, при создании которой принимались бы во внимание культурные особенности (моя методология - не исключение). Впрочем, я знаю людей, которые учитывают местные культурные особенности при формулировании методологических рекомендаций. Конечно, я нисколько не тешу себя мыслью, что смог в этом коротком посте передать всю глубину и ценность изложеных в статье идей, однако надеюсь, что убедил многих в том, что статья достойна быть прочитанной.

Posted by Vitalii Tsybulnyk on Thursday, July 9, 2009 8:29 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Распределённый мозг муравьиной семьи

Рассуждая сегодня с Alex'ом Kisialiou по пути на работу об особенностях организации процесса разработки в Microsoft, на ум пришла аналогия с социальными насекомыми - муравьями и пчёлами. Прийдя на рабочее место, первым делом прошвырнулся по интернету и натолкнулся на вот эту замечательную статью, которой не смог не поделиться. В статье приводится замечательный на мой взгляд вариант решения загадки интеллектуального поведения муравьиной колонии по сравнению с очень слабым интеллектом каждой особи. И хотя статья задаёт больше вопросов, чем даёт ответов, её идея мне очень понравилась, т.к. лежит целиком и полностью в области построения сложных распределённых вычислительных систем.  Всем любознательным людям настоятельно рекомендую прочитать о тех невероятных вещах, которые совершают колонии муравьёв, и которые бесспорно доказывают, что муравьиная семья обладает не просто уникальным набором приспособленческих рефлексов, а даже скорее выдающимся для животного мира интеллектом. Само по себе это утверждение не вызывало бы особого удивления или возражений, если бы не 2 неоспоримых факта: - Каждый отдельный обитатель муравейника - это просто мелкое суетливое насекомое, в действиях которого часто трудно найти какую-либо логику и цель. Муравей перемещается по неожиданным траекториям, тащит в одиночку или в группе какие-нибудь грузы, но обычно трудно проследить за его работой от начала до результата. - В муравьиной семье не обнаруживается никакого "мозгового центра", который управлял бы общими усилиями для достижения желаемого результата. Больше того, анатомия отдельного муравья не позволяет поместить этот "мозговой центр" в отдельном муравье. Слишком малы физические размеры его нервной системы, и слишком велик объем программ и накопленных поколениями данных, необходимых для управления жизнедеятельностью муравейника. Для обьяснения этой загадки автор предполагает, что колонией управляет коллективный "мозг большой мощности, разбитый на большое количество малых сегментов, каждый из которых размещен в нервной системе одного муравья. Для того чтобы эти сегменты могли работать как единый мозг, надо соединить их линиями связи и в набор программ мозга включить программу-надзирателя, которая следила бы за передачей данных между сегментами и обеспечивала нужную последовательность их работы. Кроме того, при построении такого мозга надо учесть то, что некоторые муравьи - носители программных сегментов - могут умереть от старости или погибнуть в тяжелой борьбе за выживание, а с ними погибнут и расположенные в них сегменты мозга. Чтобы мозг был устойчив к таким потерям, необходимо иметь резервные копии сегментов." К сожалению, автор не даёт конкретного решения проблемы эффективной связи между сегментами, расположенными в нервной системе отдельных муравьев, однако он показывает принципиальную возможность такой связи и приводит круг вариантов для поиска ответа на этот вопрос. "Для объяснения того, почему линии связи у коллективных насекомых еще не обнаружены, можно привести много различных причин - от вполне реальных (недостаточная чувствительность исследовательской аппаратуры) до фантастических. Проще, однако, допустить, что эти линии связи существуют, и посмотреть, какие следствия из этого вытекают." А следствия вытекают весьма, на мой взгляд, занятные: - Прямые наблюдения за муравьями подтверждают гипотезу о внешних командах, управляющих поведением отдельного насекомого. Типичным для муравья является неожиданное и резкое изменение направления движения, которое нельзя объяснить никакими видимыми внешними причинами. Часто можно наблюдать, как муравей на мгновенье останавливается и неожиданно поворачивает, продолжая движение под углом к прежнему направлению, а иногда и в обратную сторону. Наблюдаемую картину можно правдоподобно истолковать, как "остановку для приема управляющего сигнала" и "продолжение движения после получения приказа о новом направлении". При выполнении какой-либо трудовой операции муравей может прервать ее и либо перейти к другой операции, либо двигаться в сторону от места работы. Такое поведение также напоминает реакцию на внешний сигнал. - Очень интересен с точки зрения гипотезы супермозга феномен так называемых ленивых муравьев. Наблюдения показывают, что не все муравьи в семье являются образцами трудолюбия. Оказывается, примерно 20% муравьиной семьи практически не принимает участия в трудовой деятельности. Исследования показали, что "ленивые" муравьи - это не муравьи на отдыхе, которые после восстановления сил включаются в работу. Оказалось, что если удалить из семьи заметную часть работающих муравьев, то соответственно повышается темп работы оставшихся "работников", а "ленивые" муравьи в работу не включаются. Поэтому их нельзя считать ни "трудовым резервом", ни "отдыхающими". Можно предположить, что именно "ленивые" муравьи являются носителями специализированных, особо важных сегментов распределенного мозга. Эти сегменты могут иметь различное назначение, например выполнять функции поддержания целостности мозга при гибели отдельных муравьев, собирать и обрабатывать информацию с сегментов нижнего уровня, обеспечивать правильную последовательность выполнения задач супермозга и т. п. Освобождение от трудовой деятельности обеспечивает "ленивым" муравьям повышенную безопасность и надежность существования. Уже сегодня можно говорить, что концепция распределенного мозга позволяет непротиворечиво объяснить загадку сверхсложной жизни муравьиной семьи. Однако для меня самый интересный вывод состоит в том, что вся эта теория, начиная от гипотезы о структуре распределенного мозга, топологии сети, объединяющей его сегменты, и заканчивая базовыми принципами резервирования внутри нее, наглядно демонстрирует факт существования многих концепций вычислительных систем в живой природе и тем самым срывает с Человека лавры творца и первооткрывателя в этой области.

Categories: Books & Articles
Posted by Vitalii Tsybulnyk on Wednesday, July 8, 2009 9:14 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Как удерживать программистов

Это последний пост из серии постов по книге Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. И вопрос в нём поднимается, пожалуй, самый сложный. Итак, вы успешно наняли подходящих людей и сфоримировали настоящую команду. К сожалению, на этом всё только начинается. Как сохранить эти непростые достижения подольше? Как удержать программистов от ухода? Я уже написал об этом несколько постов, раскрыв некоторые моменты: мотивация, антипаттерны руководства и сбаллансированные отношения руководитель-подчинённый. Однако ввиду важности, сложности и неоднозначности вопроса, хочется процитировать ещё несколько интересных моментов, касающихся аттестации и зарплаты: • Не думайте, что, наняв сотрудника, вы заключили с ним договор раз и не всегда. Вы должны нанимать сотрудника постоянно. Успешно работая в своей области, сотрудник приобретает новые знания и опыт, следовательно, стоимость его услуг растет. Поэтому его необходимо перекупать, пока это не сделали конкуренты, если, конечно, вы не стремитесь стать для них «кузницей кадров». • Пересмотр договора о найме, «по договоренности», без прозрачной процедуры дезориентирует и демотивирует сотрудников. В силу своей интроверсии, программист, как правило, предпочтет найти повышение зарплаты в другой компании вместо того, чтобы просить об этом свое начальство. Поэтому, настоятельно рекомендую, проводите периодический пересмотр условий договора - аттестацию. • Кто оценивает? В первую очередь, руководство: линейный руководитель и менеджеры проектов, в которых участвовал данный сотрудник. Однако, не менее важны экспертные оценки, которые ставят люди, взаимодействующие с этим сотрудником на разных уровнях, коллеги, смежники, подчиненные, клиенты. В западной литературе этот подход называется оценка по методу «360 градусов» • Еще один важный и необходимый результат аттестации – план развития, - какую новую ступень карьерной лестницы будет достигать сотрудник и что ему необходимо сделать, чтобы на нее перейти. Что изучить и освоить: новые технологии (согласуем с личными целями и стратегическими потребностями компании), смежные специальности (снижаем риск в случае увольнения коллеги). Каких результатов добиться. Поставленные цели должны соответствовать широко известному в западном менеджменте критерию SMART, представляющему собой аббревиатуру из пяти английских слов: Specific (конкретный), Measurable (измеримый), Achievable (достижимый), Relevant (сопоставимый) и Timebound (определенный во времени). • При решении вопроса "Сколько надо платить программисту?" необходимо помнить, что участник команды это не «винтик», как думают некоторые CEO, который можно легко заменить, купив на рынке аналогичный. Я не утверждаю, что программисты незаменимы. Заменимы и еще как. На сегодняшний день средняя текучесть кадров в ИТ составляет по моим оценкам 20-30% в год, однако, отрасль не только не рухнула, но и успешно развивается. • Как правило рыночная «вилка» вознаграждения для данной квалификации известна, допустим от X до 1.5*X. Можно рискнуть и платить по нижней планке X. Однако, возможность получать в 1.5 раза больше за ту же работу, скорее всего перевесит все остальные стимулы, для удержания специалиста в данной компании. Эта ситуация усугубляется еще и тем, что «охотники за головами» делают разрыв в вилке еще больше, чтобы побыстрее перекупить квалифицированные кадры. Далее в книге идёт очень скурпулёзный рассчёт стоимости замены уволившегося сотрудника. Итоги этого рассчёта впечатляют: даже не учитывая затрат на оплату услуг рекрутеров (которые до недавнего времени стоили весьма немалых денег) для компании с доходностью 25% "мгновенная" замена специалиста с зарплатой $2000 может стоить до $27,000. В статье берётся "время адаптации" равным 6 месяцев, но даже если принять более реалистичные для нашего аутсорса 2-3 месяцев и компанию с меньшими накладными расходами, то всё равно затраты на замену специалиста составят не менее полугодовой зарплаты этому сотруднику, что совсем не легко понять "интуитивно". Какой отсюда следует вывод - каждый может решить для себя сам, однако даже просто обладание такой информацией, на мой взгляд, может повлиять на отношение к этому вопросу.

Posted by Vitalii Tsybulnyk on Tuesday, June 16, 2009 7:29 AM
Permalink | Comments (3) | Post RSSRSS comment feed

Как принимать собеседование у программистов

Это ещё один пост из серии наиболее интересных для меня глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Сегодня замечательная тема, одна из моих самых любимых. Эта тема интересна и полезна не только тем кто принимает или собирается принимать собеседованя у кандидатов и хочет отточить свой подход к этоми непростому делу. Эта тема полезна всем без исключения участникам трудового процесса, т.к. позволяет не только научиться успешному прохождению собеседования, но и научиться принимать собеседование у компании, научиться делать верные выводы не только о том, касколько вы подходите компании, но и насколько компания подходит вам. Привожу здесь наиболее понравившиеся мне моменты, но если тема интересна вам, лучше прочитайте саму книгу • Необходимо помнить, что мотивация разработчиков ПО начинается с приема на работу. В старой экономике людей нанимали за умения и обучали нужному отношению к делу. В новой экономике необходимо поступать с точностью до наоборот: нанимать за нужное отношение к делу и учить необходимым умениям. • В настоящее время нет каких-либо достоверных формальных методик определения квалификации программиста. Мой опыт показывает достаточно значимую корреляцию хороших способностей к программированию и сверхвысокого значения IQ . Высокий балл диплома и престижное математическое или техническое образование свидетельствует об общих способностях кандидата успешно осваивать новый материал. Диплом о престижном высшем образовании немаловажен для хорошего программиста, хотя и не является необходимым условием. • Отдельно остановлюсь на тестах и практических заданиях по специальности. Относительно их необходимости у меня имеются большие сомнения. Как правило, технические тесты ориентированы на проверку узкоспециальных знаний: структур данных, алгоритмов, конкретных стандартов и API, и т.д. Правильный/неправильный ответ на вопрос: «i=1; i = i++ + ++i; чему равно i?», - мало о чем свидетельствует. Попытки давать кандидатам олимпиадные задачки по программированию, или задачки из книжки «Математические головоломки», у меня, как правило, ассоциируются со стремлением, возможно, не очень успешных вчерашних студентов к самоутверждению или с желанием продемонстрировать кандидату его несостоятельность, чтобы затем снизить предложение по зарплате. Я применял тесты по специальности - несколько десятков простых вопросов на 15-20 минут по базовым понятиям стека технологий таких, которые просто невозможно не знать, если ты имеешь практический опыт в данной области. Результаты этого теста использовались только для того, чтобы выяснить, в какой области кандидат более уверенно ориентируется и адекватнее позиционировать его среди имеющихся направлений разработки. • Технические тесты могут продемонстрировать уровень IQ и эффективность левого полушария, возможности которого подтверждены, как правило, дипломом о высшем образовании и всем успешным опытом предыдущей работы. Часто при обсуждении данного тезиса меня спрашивали: «А вдруг кандидат наврал о прошлом опыте?» На мой взгляд, одного двух вопросов с просьбой уточнить некоторые конкретные технические детали достаточно, чтобы рассеять или подтвердить подобные сомнения. И еще, если вы не в состоянии распознать то, что человек выдает себя не за того, кто он есть на самом деле, возможно, вам еще рано руководить людьми. • Креативность и эффективность человека в командной разработке зависят в первую очередь от уровня его эмоционального интеллекта, EQ и деятельности правого полушария: целеустремленность, воля, эмпатия, интуиция, способность к эвристическим суждениям. Я, к сожалению, пока не встретил достоверных тестов правого полушария. Поэтому слушаем, слушаем и еще раз слушаем. А главное слышим! При отборе кандидатов только очное интервью «глаза в глаза» и личный опыт работы с людьми позволят вам создать эффективную программистскую команду. • При проведении технического интервью следует придерживаться следующих основополагающих принципов: - Помните, вы ведете переговоры с потенциальным партнером по бизнесу, а не пытаетесь «купить на рынке товар подешевле». - Каждый человек уникален и ему присуща своя ценность. Если вам нечего предложить кандидату, то это не значит, что он «лузер». - Имейте в виду, что несправедливо обиженный кандидат - пятно на бренде компании. Сегодня это значит не меньше, чем несправедливо обиженный клиент. - Люди не рождаются победителями, они ими становятся. Кандидата стоит нанимать только в случае, если вы сумеете предоставить ему эту возможность. - «Программист - это не профессия, это образ мышления», (с) программисты. • Проводить интервью, желательно вдвоем с человеком, который будет непосредственно руководить или работать с кандидатом. Это позволит быть более объективным, посмотреть на кандидата с «разных сторон» и лучше его понять. Ваша задача при проведении интервью - получить ответ на 3 вопроса: 1. Знает дело? 2. Умеет его делать? 3. Хочет его делать? От себя: это как раз то, что я называю опыт, талант и старание. • Смена работы это всегда «стресс», который, по мнению психологов, занимает по значению 3-е место после развода семьи и пожара. Помогите кандидату прийти в себя. В противном случае вы будете беседовать с другим человеком. • Принимать решение следует сразу. Возможно, понадобится 5 мин. посоветоваться с коллегой. Не стоит откладывать решение. «Я могу предложить Вам…» Далее должны следовать описание позиции, должностных обязанностей и размера компенсации. Возможно, эта будет другая позиция, а не та, на которую, кандидат изначально позиционировал себя, если, на ваш взгляд в этой роли он будет более эффективен. Обсудите с кандидатом ваше видение его места в проекте. •  Если вы не смогли в ходе интервью снять все сомнения, не берите. Доверяйте своей интуиции. Лучше ошибиться и не взять достойного кандидата, чем рискнуть и получить «проблему». Будьте честны. Имейте волю отказывать: «Я могу предложить Вам…» Далее перечень конкретных отсутствующих знаний и навыков, приобретение которых позволит кандидату, занять данную позицию в будущем. Кандидаты возвращаются! Не стоит отказывать в стиле «Если будет принято положительное решение, мы Вам обязательно позвоним». Это, скорее всего, ложь. Не стоит подрывать доверие к своей компании.

Posted by Vitalii Tsybulnyk on Tuesday, June 16, 2009 6:54 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Мотивация и опыт

Сегодня я продолжу знакомить вас с идеями полюбившейся мне книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Довольно интересным и поучительным мне показался раздел о различной мотивации программистов в зависимости от их опыта. Само это утрверждение отнюдь не ново и, я думаю, очевидно для большинства менеджеров. Однако впервые я встретил цифровые значения (пусть и отражающие грубые оценки), благодаря которым можно учитывать долю различных стимулов в мотивации сотрудника: Потребности Профессионализм Начинающий Опытный Мастер Материальные (зарплата, условия труда, социальный пакет и проч.) 50% 20% - Безопасности (стабильность компании, востребованность технологии проекта на рынке труда, возможность повысить свою квалификацию) - 20% - Принадлежности (возможность учиться у более опытных коллег, опыт участия в успешном проекте, признание в коллективе) 40% 20% 10% Самоуважения (развиваться, делать что-либо лучше других, повышение в должности, самостоятельность и ответственность в работе) 10% 30% 40% Самоактуализации (амбициозность целей проекта – сделать то, что никто не делал или не смог сделать) - 10% 50% При этом пропуск в той или иной графе свидетельствует скорее не об отсутствии соответствующей потребности, а о том, что при помощи дополнительного удовлетворения этой потребности не получится мотивировать данного специалиста. Например, для профессионала материальные потребности и потребности безопасности не играют существенной роли, поскольку, если они в достаточной степени не удовлетворены, он просто меняет работу и больше не думает о них. Приведу также и авторские комментарии к этой таблице:  • Для начинающих программистов хорошим стимулом является само участие в успешном проекте (может быть в первом в их жизни), возможность учиться ремеслу у более опытных и искушенных коллег. • Для опытных программистов хорошим стимулом может служить новизна и востребованность на рынке труда технологий, используемых в проекте (потребность безопасности). Для них также существенны сложность и самостоятельность (потребность самоуважения) в решении поставленных задач. Как правило, я стремлюсь ставить задачи примерно в 1,5 раза сложнее, чем те которые данный программист решал ранее. Для опытного программиста каждая новая задача должна предоставлять дополнительную возможность доказать свой профессионализм. • Сложнее дело обстоит с суперпрограммистами. Их главным мотивом, как правило, служит самоактуализация, поэтому они стремятся решать задачи, которые до них еще никто не делал. Оптимальное их место в проекте - системная архитектура и реализация архитектурно значимых компонентов - скелета системы. При правильной мотивации оставшаяся часть их потребностей принадлежности и самоуважения реализуется через обучение коллег и передачу им своего опыта. На эту деятельность следует планировать до 50% времени суперпрограммиста. Суперпрограммист в проекте должен играть роль технического лидера, который ведет за собой остальных участников под лозунгом: «Делай как я!». Он всегда должен быть готов продемонстрировать, как можно решить эффективно любую задачу в проекте. Вывод, который отсюда следует это то, что на серьезный проект, надо набирать программистов разной квалификации. И начинающих, и звезд. Если вы берете в проект суперпрограммиста, то должны быть уверенным, что вы сможете эффективно использовать его опыт и найдете достойную задачу, которая его заинтересует.

Posted by Vitalii Tsybulnyk on Tuesday, June 16, 2009 5:55 AM
Permalink | Comments (0) | Post RSSRSS comment feed

От группы к Команде

Это ещё один пост из серии наиболее интересных для меня глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Итак, все знают, что наиболее эффективной структурной единицей в процессе разработки софта есть Команда, однако многие считают, что Команда - просто группа людей с определёнными знаниями и умениями. К сожалению, всё не так просто. Архипенков приводит следующие характеристики, которые должна приобрести группа, чтобы превратиться в Команду:   Группа Команда Цель Ставиться узкая задача, общие цели не проясняются Ясные, принятие всеми цели и стратегия их достижения Участие в работе Выполнение должностных инструкций и распоряжений Активная позиция, нацеленность на результат, личная ответственность Ролевая структура Строгое распределение ролей, должностей, обязанностей Разделение компетенций. Гибкая структура. Ротация ролей Руководство Администрирование, наличие формального лидера - начальника Лидерство на основе компетентности и доверия, наставничество, помощь и поддержка Принятие решений В основном приказы, и решения принятые большинством Эффективные процедуры принятия решений на основе доверия и взаимовыгоды Конфликты Замалчивание, сокрытие, игнорирование Признание, интеллектуальная конкуренция, эффективное разрешение: «мы по одну сторону баррикады, а проблема с другой» Взаимодействие Закрытость, избегание критики, принцип «не высовываться» Доверие, свобода, проявление инициативы Коммуникация Через формального лидера, служебная переписка Открытость. Уверенность друг в друге и взаимное уважение Творчество Стереотипность, работа по правилам Гибкость и адаптивность. Непрерывное совершенствование и рост компетенций. Раскрытие творческого потенциала каждого Также весьма полезно знать стадии, которые проходит на этапе своего формирования Команда: • Forming (Объединение) • Storming (Разногласия и конфликты) • Norming (Становление) • Performing (Отдача) • Reforming (Расформирование) И ещё много всего полезного и поучительного о Командах есть в этой книге, обязательно прочтите её.

Posted by Vitalii Tsybulnyk on Saturday, June 13, 2009 5:06 PM
Permalink | Comments (3) | Post RSSRSS comment feed

Паттерны параноидального менеджмента

На написание этого поста меня натолкнула одна из глав книги Сергея Архипенкова “Руководство командой разработчиков программного обеспечения”. Остальные главы не менее достойны быть обсуждёнными, так что этот пост может стать лишь началом целого цикла. Для тех, у кого нет времени или желания читать всю книгу, настоятельно рекомендую просмотреть хотя бы небольшую заметку как раз об антипаттернах менеджмента, взятых из этой книги. Приведу здесь лишь те "паттерны", с которыми лично мне приходилось сталкиваться в своей практике в порядке от наиболее частых и ярких к более редким. Уверен, вы прочитаете здесь много до боли знакомого: • Руководитель не умеет управлять приоритетами, постоянно занимается пожаротушением, полностью погружен в решение неотложных вопросов. Времени на уточнение целей, разработку стратегии, адекватное планирование, оценку и повышение эффективности применяемых процессов не остается. Героический Темп поступления проблем превышает скорость их решения. Большинство задач, которые получают участники проекта, имеют наивысший приоритет и срочность. Работа постоянно выполняется под давлением нереальных сроков. • Замыкание всех внешних и внутренних потоков информации на себя. Фильтрация и искажение информации в личных интересах. Зависимость исполнителей от более информированного начальника. • Отсутствие делегирования. Строгий контроль всех работ через активное личное наблюдение. Руководитель замыкает на себя принятие решений по всем вопросам. Считает себя самым компетентным. Влезает во все самые мелкие работы. Навязывает собственные идеи. «Просто, делай, как я сказал!» Жестко контролирует каждый шаг исполнителей. • Руководитель, который полностью зависим от Босса. Всегда согласен с его мнением, как бы оно не расходилось с его собственными взглядами и мнением его команды. • В случае провала проекта надеется свалить вину на команду. Если же проект окажется успешным – присваивает успех себе. Культивирует любимчиков в команде, которые никогда с ним не спорят. Постоянный поиск виновных и «козлов отпущения». • Безграничная вера руководителя в методологию с большой буквы «М» - всеобъемлющую теорию того, как следует решать весь класс задач, возникающих в процессе производства. Многоступенчатая бюрократия. Все процессы регламентированы. Применяемые методы ограничены. Инструкции постоянно разрастаются вследствие попыток учесть все возникающие новые ситуации. Внедрены всеобъемлющие нормы и метрики. • Непрерывная критика и понижение самооценки. Постоянные перемещения людей по горизонтали и вверх-вниз. Правила меняются по ходу игры.

Posted by Vitalii Tsybulnyk on Saturday, June 13, 2009 12:11 PM
Permalink | Comments (5) | Post RSSRSS comment feed