Причина недопонимания между нами и неверного использования технологий. По мотивам статьи «Пять миров» (ПО)
Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга… Joel Spolsky
Статья Джоэла о Пяти мирах (программного обеспечения) вышла в 2002 году. За прошедшие 14 лет успели образоваться новые миры: Мобильные приложения и Облака, — но соль статьи осталась неизменной.
Одна и та же технология в разных условиях будет давать разную эффективность.
Когда мы обсуждаем опыт применения какой-то технологии, мы часто не обращаем внимания на контекст её применения из-за этого возникает недопонимание, неверное толкование и применение технологий.
Представьте,
Мы на Земле, наш друг Марк на Марсе. У нас стоит одна и та же цель, вырастить в своём Мире урожай картошки. Технологию будем использовать одинаковую «посадка в грунт», а результаты получим разные так как влияние факторов/переменных разное для каждого из Миров.
Это кажется очевидным, но факты из жизни говорят об обратном.
Факты игнорирования контекста
Факт №1 про Консультантов
Каждый год мы проходили аудит зрелости процессов разработки по модели CMMI и от ребят консультантов не раз приходилось слушать, что у нас «лишнее» и что нам «нужно» сделать, чтобы было лучше. При этом ребята опираются не на контекст, а на список практик, который может быть вообще использован для повышения «мощности» процессов разработки.
Ребята, у вас длинный цикл выпуска релиза, одна из причин — вы пишите ТЗ до начала разработки. Оформляйте документацию на систему либо в процессе, либо после окончания работ, этим вы сократите срок выпуска релиза на две недели.
Выглядит как дельное предложение. Теперь наложим контекст.
Корпоративная ИС переваривает операции на 60 млрд.рублей в год, в день через неё проходит 170 млн.рублей. В системе трудится более 2000 человек. Похожий на наш бизнес — Московская Биржа и поддерживаемые ею торговые операции.
Особенность нашей КИС в том, что она монолитна. Если обновляется один из функциональных блоков внутри, ошибки в нем способны вывести из строя всю систему или рабочий процесс. Для компании это означает финансовые потери и последующие перегрузки в работе компании, так как пропущенную работу на 170 млн.рублей нужно сделать и нагнать «простой».
На фондовом, валютном и срочном рынках Московской биржи нештатная ситуация … Последний раз биржа приостанавливала торги 1 сентября, но это коснулось только секции «Основной рынок». Этот сбой стал четвертым за последние четыре месяца. — Lenta.ru
Теперь контекст даёт возможность сопоставить что лучше
- выиграть 2 недели из 3-х месячного цикла выпуска релиза, но значительно увеличить риски простоя,
либо
- пока оставить ТЗ в том месте где оно есть, минимизировав риски, и искать другие варианты сокращения длительности релизного цикла.
В нашем случае в работе параллельно находились 3 релиза и новый выходил каждый месяц. Для нас вопрос стоял не в том, чтобы сократить релизный цикл, а стоит ли дальше наращивать частоту выпуска релизов: выпускать не раз в месяц, а раз в две недели.
И в концептуальном плане начинать двигаться к вытаскиванию из КИС каждого функционального блока в самостоятельное приложение, сделав КИС платформой для них. Это позволит делать одновременно хоть 10 релизов по числу приложений.
Факт №2 про Руководство
Иногда доводится слышать от новых высоких руководителей такой посыл:
Ребята, у меня на прежнем месте процессы были устроены вот так, проблем не было, поэтому мы будем переходить на них.
Там это не Здесь … Не торопитесь выступать капитаном очевидностью и пытаться открыть ему глаза на это. Моя личная статистика показывает, что вас расценят как отказывающегося сотрудничать и запишут в «чужие», в системе координат «свой | чужой».
Дождитесь от руководителя конкретных действий и уже их сталкивайте с реальностью.
За 6 лет работы в компании Руководитель Проектного Офиса менялся трижды, один раз вместе со всей командой Офиса.
Меня печалят попытки без разбора натянуть все проекты по созданию, внедрению и развитию ПО на соответствие требованиям PMBoK или ставшими модными Scrum или Kanban.
Есть заточенные под ИТ-проекты методологии, которые делятся на методологии создания, внедрения и развития.
- SureStep и ASAP для проектов внедрения корпоративного ПО.
- RUP и MSF как методологии создания больших ИТ-решений.
- Agile:Scrum как методология создания «малых» форм и развития существующих.
И каждый из Миров ПО вносит в них свои корректировки.
Выход: Использовать желание и энергию руководителя на реализацию улучшений, начав с тех участков где они нужны и/или там, где то что он хочет даст положительный эффект.
Факт №3 про Хабравчан
Проскакивает это и в обсуждениях на хабре. Из недавнего «О рабах, героях и рабах-героях»
Увидел в вашей классификации «быдло», и дальше читать не стал. Если в вашем анализе людей присутствует такое понятие, это означает, что у вас еще недостаточно понимания людей и мира, чтобы делать какие-либо выводы.
Человек статью не дочитал и в контексте применения «термина» не разбирался, но определил, что Автору недостаёт понимания людей и мира.
Следом идёт содержательный комментарий от другого Читателя:
Автор, похоже, неудачно выбрал термин. Я тоже не сразу понял этого термина, слишком специфические значения в него вкладывают, в том числе оскорбительные.
С другой стороны подобрать более точное слово имеющее значение «люди, выполняющие тяжёлую работу и занимающие низкое социальное положение, духовно неразвитые, бессловесно покорные люди, подчиняющиеся чужой воле и позволяющие себя эксплуатировать» может быть затруднительно.
Способ определить, что контекст не учтен и восстановить его
Верный способ определить, что контекст не учтен — Автор статьи в явном виде не указал его, но при этом кажется:
- что в описанном решении много лишнего;
- что знаешь способ как сделать лучше.
Оно может и так, но точно не стоит торопится с тем, чтобы заявить его правильным, что он лучше.
Можно нарваться, на то, что сообщество в жесткой форме укажет что мы тут обсуждаем «мягкое», а вы про «горячее».
- Из какого Мира ПО знания и опыт, изложенные в статье?
- Зачем и почему Автор сделал именно так?
- Какие альтернативы рассматривал Автор, между чем выбирал?
- Какие входные параметры у решенной автором задачи?
Возможно, не на всё удастся ответить самому и понадобится помощь Автора в ответе на них. Задав уточняющие вопросы Автору вы также поможете ему лучше понять что он Сотворил.
И уже после этого, погрузившись в контекст, примерять свои варианты к задаче и изготовленным решениям.
Всем хорошего «урожая картошки» в вашем Мире и содержательных обсуждений в комментариях.
Статья Джоэла на русском
Статья Джоэла на английском
Кто такой Джоэл Спольски? — статья Wiki на русском и английском.
Иллюстрации из фильма Марсианин.
Автор: