Высокая неопределенность

Если есть сигма-бой, то должен быть и 3-сигма-бой и тем более 6-сигма-бой #meme

Мои знакомые из Сберздоровья опять делают митап. Приходите на интерактив, в прошлый раз было интересно)

Пятничный пост Недавно узнал, что папка и каталог - не синонимы. Папка (Folder) - это элемент UI, окошко с иконками. Папки не обязаны как-либо быть представлеными на диске, а иконки в них не обязяны соответствовать файлам Каталог (Directory) - элемент файловой структуры, с ним можно работать и без папок (в той же командной строке никакхи папок не подразумевается). Вряд ли когда-то это знание вам пригодится или будет полезно в реальной жизни. Но теперь вы тоже прокляты этим знанием :) #glossary #meme

Шаблон 7 Product Dimensions В прошлой жизни на одном из проектов применяли такой шаблон описания требований (взято из книжки discover to deliver) Лучше, чем ничего. #Reqs #Шаблоны #Требования

В ответ на пост Нашел статью на тему "Год - это не мера опыта". Созвучно с моими мыслями про опыт. И тем более опыт - не мера качественных постов. Ровно как и качественные посты - не мера хороших скиллов! Вдвойне тяжелее, когда и посты не качественные, и скиллы не хорошие 🙂 Последнее время очень принебрежительно смотрю за постами ит-блогеров, в том числе системных аналитиков, в Инсте. Как-то раз к нам в компанию на вакансию откликлуся блогер, который обучает других людей. Априори я был убежден, что собеседование он пройдёт хорошо. Ведь в инсте у него полно рилсов на проф.тему и даже есть курсы "как пройти собес". Но по факту, как мне сказали коллеги, кто его собеседовал, оказалось, что знания там тупо зазубрены 🙁 Ситуация 1-в-1 с описанной у Фейнмана (кто не читал автобиографию, рекомендую, мне очень зашло, я даже думаю, что стал бы физиком, если бы прочитал их раньше): Я обнаружил очень странное явление: я задавал вопрос, и студенты отвечали, не задумываясь. Но когда я задавал вопрос еще раз – на ту же тему и, как мне казалось, тот же самый вопрос, они вообще не могли ответить! Например, однажды я рассказывал о поляризации света и раздал им всем кусочки поляроида. Поляроид пропускает свет только с определенным направлением поляризации. Поэтому я объяснил, как определить направление поляризации света по тому, темный поляроид или светлый. Сначала мы взяли две полоски поляроида и вращали их до тех пор, пока они не пропустили максимум света. Теперь мы могли сказать, что две полоски пропускают свет, поляризованный в одном направлении: что пропускает один поляроид, может пройти и через второй. Но потом я спросил, можно ли, имея всего один кусок поляроида, определить, в каком направлении он поляризует свет. Они совершенно не представляли себе. Я знал, что это требует известной доли находчивости, поэтому я подсказал: «Посмотрите на залив. Как от него отражается свет?» Все молчат. Тогда я сказал: – Вы когда-нибудь слышали об угле Брюстера? – Да, сэр. Угол Брюстера – это угол, отражаясь под которым от преломляющей среды, свет полностью поляризуется. – В каком направлении свет поляризуется при отражении? – Свет поляризуется перпендикулярно плоскости падения, сэр. Даже теперь я не могу этого понять. Они знали все наизусть. Они знали даже, что тангенс угла Брюстера равен показателю преломления! Я сказал: «Ну?» По-прежнему, ничего. Они только что сказали мне, что свет, отражаясь от преломляющей среды, как, например, воды в заливе, поляризуется. Они даже сказали, в каком направлении он поляризуется. Я сказал: «Посмотрите на залив через поляроид. Теперь поворачивайте поляроид». – О-о-о, он поляризован! – воскликнули они. После длительного расследования я, наконец, понял, что студенты все запоминали, но ничего не понимали. Отдельный респект от автора поста тем, кто вдумчиво читает этот отрывок. Напишите что-нибудь в комментарии, посмотрим, сколько вас. Когда они слышали «свет, отраженный от преломляющей среды», они не понимали, что под средой имеется в виду, например, вода. Они не понимали, что «направление распространения света» – это направление, в котором видишь что-то, когда смотришь на него, и т.д. Все только запоминалось, и ничего не переводилось в осмысленные понятия. Так что, если я спрашивал: «Что такое угол Брюстера?», я обращался к компьютеру с правильными ключевыми словами. Но если я говорил: «Посмотрите на воду», – ничего не срабатывало. У них ничего не было закодировано под этими словами И теперь я очень скептически отношусь ко всем постам ит-блогеров. Особенно к постам в духе "Я попробовал работать в компании Х и понял, что это не моё". Я всегда додумываю за автора, что он просто не понятул, потому что снимать рилсы про работу и делать работу - это две большие разницы (я-то уж точно знаю, сколько этих рилсов сам снял, не пересчитать) #ворчание

Завершающий пост про цитаты из "Жемчужин" Вигерса. Про шаблоны. В начале карьеры мне казалось, что шаблоны – это что-то скучное и ограничивающее, убивающее творческий порыв. Думал, зачем загонять себя в рамки? Цитата Вигерса про меня: Некоторые люди не используют шаблоны, опасаясь, что они наложат на проект излишние ограничения. Но постарев, я понял, что шаблоны – это не оковы! Под шаблонами я подразумеваю любые готовые "формы" для требований, тикетов, расчетов, постов в тг (у меня пока нет), промтов в аи, да чего угодно, что помогает нам в работе. Даже процесс – это, по сути, шаблон последовательности действий с ожидаемым результатом. Сейчас я думаю, что шаблоны, наоборот, освобождают место для творчества! Один раз продумал рутину, зафиксировал в шаблоне, и дальше просто заполняешь его, концентрируясь на уникальных аспектах задачи. Вигерс: Подобно другим важным компонентам процесса, хороший шаблон поддержит вашу работу, а не помешает ей. Если шаблон "скрипит" и мешает – это сигнал, что пора его обновить! Важно помнить о здравом смысле. Шаблон – не догма! Если он не подходит для конкретной задачи, смело отказывайтесь от него полностью или частично. Шаблон - это основа, отправная точка. Он отлично решает проблему чистого листа. И в зависимости от контекста может либо частично подходить, либо совсем не подходить. Вигерс: Создатели документов должны общаться с их получателями и адаптировать стандартный шаблон под конкретные потребности. Для требований шаблон может служить отличным чек-листом! Даже если какой-то раздел не нужен в итоговом документе, мы хотя бы имеем шанс осознанно отказаться от него, а не просто случайно забыть подумать про этот раздел. Так что шаблонно призываю всех использовать шаблоны! #quote #Вигерс #шаблон

Очередная порция цитат из Вигерса. На этот раз про культуру организации. Умничать и обобщать сегодня не хочется, а поделиться - хочется. Думаю, максимум у меня ещё наберется сгруппированных цитат на 1 пост. Конгруэнтность означает, что руководители и рядовые сотрудники действуют согласно заявлениям организации о ценностях, а не в соответствии с негласными правилами, которые могут противоречить официальным заявлениям Как тут не вспомнить цитату про стену из Балдеющих от адреналина Если вы на стене напишите ценности, то это ничего не поменяет И еще про выбор технологий: Организации иногда выбирают модные решения и горячие новинки в области разработки программного обеспечения, считая их волшебным эликсиром, способным решить их задачи И опять цитата: IT-подразделение в нетехнологической корпорации наследует общие культурные особенности компании И снова: Характерный признак укоренения здоровой культуры в организации, — сохранение новых взглядов, методов и моделей поведения даже после ухода ключевых руководителей. И завершаю полюбившейся мне формулировкой (мысль вроде очевидная, но сложена в слова хорошо): Иногда я не в восторге от реальности, но она — все, что у меня есть, и я должен с этим жить. #quote #Вигерс

Выкладываю первую большую цитату из Вигерса (Жемчужины разработки). Команда А экономила на проектировании и сосредоточилась на программировании; их система каждый день давала сбои. «Отряд коммандос», сформированный командой А для восстановления работоспособности системы после каждого сбоя, получил похвалу от руководства за выдающееся обслуживание клиентов Команда Б, напротив, построила свою систему, твердо придерживаясь принципов разработки качественного программного обеспечения, из-за чего задержала выпуск на несколько месяцев, но их система прекрасно работала. Эта команда не получила ни награды, ни признания. Моральный дух в команде Б серьезно пострадал, когда руководство отнеслось к ним как к неудачникам из-за опоздания, восхваляя героические усилия команды А В Вилларибо давно продолжается праздник, а в Виллабаджио всё ещё моют посуду Может быть, моя оценка очень смещена, но я воспринимаю эту цитату и целом дух книги очень однозначно: качество - это всегда хорошо. В сегодняшнем философском настроении я бы сказал, что ситуация очень сильно зависит от других параметров. Допускаю, что бывает важно первыми выйти на рынок, занять нишу, и по ходу уже чинить баги. Или проверить МВП. Или успеть до вступления закона в силу. Я бы здесь сделал акцент на ясности и управлении ожиданиями. Очень важно было проговорить с руководством, что в приоритете: сроки или качество. И сознательно выбирать, и относиться с пониманием. Но в то же самое время очень верю в ситуацию, когда со стороны руководства декларируется упор в качество (одновременно со скоростью, конечно же), а по факту поощряются "герои". На этот счёт Вигерс по-дорофеевски пишет: Если у вас нет времени сделать правильно, то где вы возьмете время сделать заново? и У организаций никогда нет времени, чтобы правильно создать программное обеспечение, но они находят ресурсы, чтобы исправить его позже. Думаю, виною всем надежда, что всё с первого подхода будет хорошо. А оно, как говорил Квартет И, никому ничего не должно. д.Боб пишет в Идеальном программисте про эту самую надежду: Надежда убивает проекты. Надежда срывает графики и рушит репутации. Не позволяйте надеяться другим. Надежду лучше "убивать". А убивает надежду ясность и управление ожиданиями. Те самые, про которые я писал выше. #quote #Вигерс

Прочитал книгу "Жемчужины разработки" Карла нашего Вигерса. По стилю и духу напоминает мне смесь Идеального программиста (ранее писал про неё тут https://dzen.ru/media/highuncertainty/robert-martin-idealnyi-programmist-dochital-odnu-iz-jeltyh-knig-diadiushki-645ff8887906327d864450a5) и Балдеющих от адреналина (https://dzen.ru/media/highuncertainty/zakonchil-chitat-de-marko-baldeiuscie-ot-adrenalina-ili-zombirovannye-shablonami-65acf0a320643e4bfa1f5fa5). 60 уроков/советов, которые автор вынес за свою карьеру в ИТ. Большинство из них очень адекватны. Хотя, конечно, есть и устаревшие. Удивился, кстати, что несколько раз Карл приводил написание книг в качестве примера проекта. Кажется, это несколько далеко от типичного проекта в ИТ со множеством задействованных людей. Думаю разобрать часть его цитат в отдельных постах. А пока приведу для затравки несколько штук: Разработка программного обеспечения не является линейным, упорядоченным, систематическим и предсказуемым процессом. Большая группа людей не способна организованно покинуть горящую комнату, не говоря уже о том, чтобы сформулировать какое-то требование Если бы каждый участник проекта имел право присутствовать на каждом обсуждении, интерпретировал информацию так же, как все остальные, и имел идеальную память, то вам никогда не пришлось бы ничего записывать. Старайтесь избегать расстановки приоритетов по децибелам ПНК - простое написание кода. НРВН — сокращение от «Ничего не работает, и всем наплевать». #book #reqs #Вигерс

Таблица, картинка и текст Встречал как-то ещё на просторах ЖЖ (ссылки не найду, даже не просите) совет: - Фиксируй одну и ту же информацию в виде таблицы, картинки и текста. В качестве картинки, естественно, может быть диаграмма или схема. Естественно, полностью дублировать документы в трех представлениях не имеет смысла. А вот если в документе есть какой-то сложный для понимания момент, то его имеет смысл представить с другой стороны. И иногда даже с третьей. Считаю этот совет годным, так как все люди по-разному воспринимают информацию. Каждый поймет что-то свое, а рассмотрение с разных сторон помогает.Кстати, не для того ли мы делаем разные модели системы? #reqs #quote

Восторг от работающего кода. Детский, искрящий. Не хочу вдаваться в исследования, но предположу, что это довольно значимый фактор в выборе профессии программиста. На днях видел, как уставший от рабочей недели коллега, из последних сил сидящий в кресле, внезапно чуть ли не подпрыгнул с радостным визгом, когда у него получилось настроить одну небольшую утилитку другому сотруднику. Многое стало понятно :) Представляете, ты что-то ввёл, написал какой-то код, а он - вжух - и выполняется компьютером. В-О-Л-Ш-Е-Б-С-Т-В-О Делаю ставку, что человеческий мозг, однажды испытав эту радость, пытается снова и снова её воспроизвести. Так и становятся программистами. А если не зацепило, то, наверное, будет сложнее. Меня определенно цепляет код, но, возможно, не так сильно, как коллегу. Еще целпяют красивые схемы :) Буду рад, если поделитесь тем, что цепляет вас. #зарисовки

Для достижения разумного баланса ни для одной эксплуатационной характеристики нельзя выбирать предельное (или близкое к предельному) значение Косяков. "Системная инженерия..." Очевидная мысль, но когда встретил её явно сформулированной, поймал это чувство: "Ну да, точно же, ведь это так и есть!" (не знаю, кстати, как оно называется) Именно это и называется отсутствием запаса прочности. Даже если остальные характеристики будут далеки от предела. Диаграмму добавил я, представляю себе эту цитату так. #quote #book