С новым 2015 годом!

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

Составьте свои(!) четыре списка:
1. Что вы перестанете делать в 2015 году.
2. Что начнете делать нового для себя.
3. Что измените и станете делать чуть-чуть (или сильно) по другому.
4. А что просто продолжите делать как есть, ибо оно уже вполне отлично получается.

Читать далее С новым 2015 годом!

Коллективная безответственность

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

 

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

Начнем с вопроса, а что мы вообще хотим от такого коллектива? К примеру у нас коллектив на заводе, или наши сотрудники в нашей компании, или ученики в классе. Вот что мы в итоге хотим от такого коллектива? Ибо от понимания наших «хотелок» сильно зависят наши действия, что и как мы будем говорить, какие стратегии работы с коллективом выберем, куда будем его вести, если вообще будем это делать.

Предположим, что нам безразличен как коллектив в целом, так и отдельные люди, его составляющие. В таком случае мы вольны делать вообще что угодно. Особенно интересная ситуация наступает, если люди не могут покинуть коллектив (нашу «подопытную группу»). И вот если так, над этим коллективом можно ставить любые «опыты», например внедряя так называемую коллективную ответственность.

Читать далее Коллективная безответственность

Персональная методология проекта

Задаетесь ли вы иногда вопросом, а ту ли методологию я, как руководитель, выбрал для своего проекта? Верной ли дорогой веду проект к успеху?

Насчет успеха — есть очень интересный отчет «Chaos Report» (пока за 2013й год) от известнейшей группы Standish Group о состоянии дел в управлении проектами со списком факторов, приводящих к успеху выполнения проекта и подробным анализом таких факторов с разных сторон и под разными углами. Рекомендую глубоко изучить его на досуге, запланировав для этого как минимум несколько часов в спокойной обстановке. Также ребята из Стратоплана регулярно проводят опрос «Какая методология используется в вашем проекте» и получают очень веселые и показательные результаты. Реальность же такова, что у меня за почти 10 лет управления проектами ни разу не получалось использовать какую-либо методологию в ее каноническом, книжном, классическом виде. Подозреваю, что у вас дела обстоят похожим образом. Всегда есть какие-то обстоятельства, которые заставляют нас из, к примеру, Scrum’а конструировать зверька под названием ScrumBut (Скрам, Но). Про более тяжелые методологии речь даже не идет. Водопад в чистом виде в software development — вообще довольно большая редкость. Периодически встречаю, что на словах он задекларирован, а в реальности по результатам аудита там что угодно, но не водопад.

Расскажу вам одну историю. Руководил я одной программой проектов (группа проектов), где в контракте было указано, что мы работаем с заказчиком по Fixed Price и у нас водопад. Нюанс был в том, что водопад был на каждый релиз, который в свою очередь длился примерно 4-6 месяцев. Такие себе небольшие водопадики, длиной до полугода. Жестокая реальность показала, что если fixed price в такой схеме еще можно сделать прибыльным, то водопад — совсем никак не приживается. Система была настолько сложная, старая, большая, связанная с еще порядка 30 другими системами, ответственная и часто используемая бизнес пользователями заказчика, что изменения приходили пачками каждую неделю. Мы никак не могли заморозить рамки проекта (scope) на срок даже в 1 месяц, не говоря уже про период в 6 месяцев. С другой стороны, более гибкая методология здесь тоже не подходила. Ответственность за корректную и стабильную работу системы настолько высока, а объем кода и модулей внутри системы настолько велик, что никак нельзя обходиться минимумом документации и хаотичной разработкой — дальнейшая поддержка всего этого хозяйства очень скоро стала бы невозможной (почти так и было, когда я пришел в эту программу).

Что же делать? Как управлять проектами, где из-за высокой сложности, объема, ответственности системы перед заказчиком и величины возможных последствий из-за простоя/поломки, требуется водопад (minimum agility), а из-за частых изменений бизнеса у заказчика требуется что-то вроде scrum’а (maximum agility)? И я нашел решение!

Читать далее Персональная методология проекта

Переобучение в IT?

В статье я НЕ буду затрагивать вопросы мотивации и целеполагания, а также крайне важного вопроса «А зачем это делать?». Если уважаемые читатели будут заинтересованы и напишут в комментариях о своем желании увидеть рассмотрение этих нюансов — готов написать продолжение статьи.

Препарировать вопрос подготовки новых специалистов я решил с двух сторон. Со стороны технической и человеческой. Технической стороной назовем некоторые знания предметной области, языка программирования, инструментария и прочие штуки. Человеческой же стороной будем считать качества: способность к постоянному обучению, умение рассуждать, абстрактно мыслить, и, что особенно важно, видеть проблему на нескольких уровнях абстракции одновременно. Джоэль Спольски (в свое время руководил проектом Microsoft Excel, а также автор интереснейшего блога для разработчиков и руководителей) прекрасно осветил обе стороны в своих статьях. В статье «Закон дырявых абстракций» речь идет про техническую сторону. В статье «Опасность обучения на Java» — про качественную.

Читать далее Переобучение в IT?