Почти никогда во всей литературе, посвящённой программированию и разработке программного обеспечения, не упоминается нечто важное, из-за чего мы иногда недопонимаем друг друга... 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 на русском и английском.
Иллюстрации из фильма Марсианин.
Комментарии (9)
dog_funtom
19.11.2016 18:16+4Раздражает уравниловка всех программистов, заставляющая этих людей тратить невероятные совместные усилия на создание какого-то эталона, подходящего всем, что заведомо бесполезно.
В копилку печальных примеров можно добавить непреходящую массу «форумов программистов» (где сидят исключительно веб-программисты), «чатиков программистов» (где сидят исключительно веб-программисты), «подкастов про программирование» (где говорят только о… да, угадали, веб-программировании; или только о серверах и хайлоаде). У этих людей и в коде кнопка называется Control, мотоцикл называется Vehicle, яблоко называется Fruit, а человек называется «LivingBeing»?
Эта статья — луч света в темном царстве. Нужно чаще поднимать эту тему. Если о ней не говорить, то она сама не рассосется.
Locolind
19.11.2016 18:44Ребята, хабровчане, обращаюсь к тем из вас, кому статья не понравилась и вы даже хотите или уже заминусовали мне карму.
Оставьте комментарий, что вам так сильно не понравилось, что вы решили не ограничиваться только минусом к статье.
grossws
20.11.2016 05:00Для меня поводом для минуса явились следующие факторы:
- статья не добавила ничего полезного (т. е. фактор полезности материала) и не является, на мой взгляд, хорошим стартером для дискуссии;
- отняла ощутимое время на прочтение;
- раздражение от тонных картинок.
Естественно, всё это субъективно.
Locolind
20.11.2016 11:27Благодарю вас и Rampages за аргументированную обратную связь.
Статья получилась полярной, по состоянию на 11:00 20.11.16, 31% голосующих читателей оценили её отрицательно, а некоторые снабдили и «подзатыльником», но не сопроводили комментарием.
Это указывает на то, что есть что обсудить и это точно не стоит игнорировать, чтобы не получить в будущем.
Вариант
— За что???
— Было бы за что вообще убил бы!
Рассматриваю в последнюю очередь, поэтому и попросил высказаться.
Про картинки
Экспериментировал с двумя сюжетными линиями, как в кино.
Решил взять Пример, который привел, и развить его.
У меня возникла мысль, что картинок получается много, поэтому убрал их внутрь спойлеров снабдив пояснениями что под ними скрывается. — по двум комментариям вижу, что спрятав их в спойлеры я проблему с «много картинок» не решил, а закамуфлировал.
Про ничего полезного и отняла ощутимое время
Если я верно понимаю, то Вы прочитав введение и отправившись под кат за что-то зацепились, за какую-то свою потребность.
Что у вас за ситуация-проблема, которая побудила вас отправиться под кат?
Минус я получил за то, что не оправдал ожиданий. Дайте мне ещё один шанс назвав свою ситуацию-проблему, вдруг у меня есть чем с вами поделится.
Rampages
20.11.2016 09:45С картинками согласен. Martian явно не вписывается. Если бы было одно изображение из Martian'a, то возможно не придал бы этому значения, но когда количество изображений превысило количество в две штуки – по какой-то причине начало вызывать раздражение, а то что они еще и под спойлерами…
Еще раздражает оформление цитат и нумерованные/ненумерованные списки… как-то между ними свободного места нету, у меня все это смешивается на экране, отступы бы между ними или цитаты оформить как-то по другому.
Идею понял, но преподнесли вы её не совсем «красиво», возможно для кого-то идея была вполне очевидна и ваша статья для них была просто ни о чем.
Rampages
19.11.2016 22:08+3В бытность пользователями, мы с друзьями смеялись над тупыми инструкциями к ПО.
В бытность работы в IT-сфере, столкнулись, с тем что пользователь получил от нас ПО на дисках, и в момент когда на экране было написано «вставьте 2-ой диск», пользователь открыл лоток привода и положил второй диск поверх первого! т.к. нигде не было написано о том. что нужно вынуть первый диск, перед тем как вставлять второй, хотя может и было где-то в инструкции к приводу (что-то типо «не вставлять больше одного диска»)… но суть не в этом, а в том что со своей колокольни многое выглядит несуразно и не к месту, а когда приходится сталкиваться с этим в жизни, то уже не до шуток…
Понимание штука такая, что если бы люди понимали друг друга, то никаких войн и конфликтов интересов в нашей истории не было бы. Практически все конфликты людей происходят от недостатка взаимопонимания. Наверное в будущем с помощью интернета можно будет синхронизировать мозги и понимать друг друга лучше, а возможно это поставить крест на нашей индивидуальности и цивилизации.
Deosis
21.11.2016 08:50Похоже надо писать 3 инструкции для пользователей:
- Краткая инструкция:
- Установите ПО
- Обычная инструкция:
- Вставьте диск с ПО в привод
- В проводнике выберите диск с ПО
- Дважды кликните на файл setup.exe
- Подробная инструкция:
- Убедитесь, что компьютер включен
- ...
- Краткая инструкция:
Vkuvaev
Один мой коллега точно отметил, что основное в профессии консультанта это слушать и слышать. Сам стараюсь следовать принципу «не навреди».
Вообще, я бы отнес описанное в статье к вопросу профессионализма, часто не хватает именно такого отношения, что в жизни, что на работе, что на Хабре.
Locolind
К принципам:
- слушать и слышать
- не навреди
я добавлю «проявлять любопытство и ковырять».Если упростить, компания приглашая консультантов ожидает получить знания которых у неё нет. Это:
Я думал над тем как извлечь из консультантов пользу так как то, что мы ждали и то, что мы получали порой не совпадали. Вот некоторые из выводов:
«глубокое знание предмета»
Лучше получать и искать на хабре.
Опубликовав свой кейс, есть высокая вероятность получить в комментариях содержательную обратную связь. Комментарии выводят на практикующих экспертов с которыми уже можно общаться лично.
Также работает и поиск по опубликованным аналогичным кейсам выводя на нужных экспертов.
«как устроены процессы у конкурентов и показатели их эффективности»
Консультанты работают как испорченный телефон. Для себя выяснил, что более эффективный способ это ходить на тематические мероприятия, где коллеги из отрасли (конкуренты), что-то о себе рассказывают и с ними лично уже более детально обсуждать их рабочие процессы.
«обобщенный мировой опыт лучших практик»
Здесь консультанты дают пользу, так как и мы и они, вместе берем какой-то любопытный материал, который им достался от головной компании, и примеряем его на нашу компанию.
Так как для ребят примерка этих «практик» ежедневная работа, а для нас единовременная активность, они в этом разбираются лучше.
«комплексное виденье»
Плохо получается у ребят, либо слишком абстрактно либо слишком узко-«в лоб».
А даже когда у ребят выходит хороший продукт, его Потребители (Руководство), порой не в состоянии его потребить.
За «комплексным виденьем» лучше не к консультантам, а руководителей отправлять в бизнес-школу.
Но Консультанты нужны и очень в следующих ситуациях: