Архив автора: Alexander Trofimov

Вот кому работы?

Image result for работа расстояние

Вы таки будете смеяться, но мне снова нужен сотрудник. На этот раз человек, хорошо разбирющийся в AD.

Я сейчас изрядно занят и не в состоянии буду сам проводить первичный отбор. Поэтому свои резюме присылать сюда: maria.ivanova@kaspersky.com. Я с Машей договорился, что все приславшие получат ответ. Если не получите в течении двух недель ничего, пишите мне, я разберусь (ответ не означает объяснения, почему принято то, или иное решение. Это просто “да” или “нет”).

Формальное описание чуть ниже, а тут, как обычно, пишу, чего мы будем ждать:

  • Понимания, как и что работает сильно выше уровня “ну я тут ставил в одной организации, ничего сложного – next-next”.
  • Именно понимания, как это работает. Так, чтобы можно было реально услышать, в каких случаях и почему нужны разные домены, а в каких OU – что нужно.
  • Трепетное отношение к своему сервису и понимание, что он нафиг никому сам по себе не нужен. Главное, что с его помощью делается. Чтобы короче: словосочетание “с моей стороны пуля вылетела” стабильно снижает карму и шансы на хорошее отношение.
  • Как всегда – лютое желание обучаться и постигать новое глубоко и качественно.

Про вилку зарплат опять не скажу – она широкая, потому что рассчитана на людей от джуниора до мэтров. формальное описание вакансии:

Обязанности:

Администрирование и развитие систем аутентификации и авторизации на базе ОС Microsoft Windows Server 2012.

Мониторинг работоспособности систем.

Диагностика и устранение сбоев, повышение надежности и доступности систем.

Управление средствами разграничения и контроля доступа, администрирование серверов и сетевых ресурсов.

Обеспечение бесперебойной работы сервисов и доступности информационных ресурсов, сохранности информации и восстановления после сбоев. Проактивная работа по предотвращению сбоев.

Проектирование новых систем в области информационной безопасности, их внедрение.

 

Требования:

Стаж работы не менее 4-х лет в должности системного администратора в крупных компаниях с большим количеством филиалов.

Уверенные знания и опыт работы в области администрирования:

·         Операционных систем Microsoft Windows Server и основных сервисов (DHCP, DNS, FS и т.д.).

·         Active Directory Domain Services (2008/2012).

Понимание принципов работы PKI, ассиметричной криптографии, протоколов аутентификации.

Знание сетевых протоколов, знание современных программных и аппаратных средств защиты информации.

Знание основ коммутации и маршрутизации на уровне CCNA (Routing & Switching).

 

Умение писать (и читать) документацию по поддерживаемым сервисам и системам.

Опыт написания и отладки сценариев на PowerShell.

Стремление находить корень проблем и применять best practices.

Английский язык на уровне, достаточном для чтения технической литературы и ведения переписки.

 

Желательно:

 

Высшее техническое образование.

Уверенные знания и опыт работы в области администрирования:

·         Active Directory Certificate Services.

·         Active Directory Federation Services.

Опыт проектирования и разработки мониторинга распределённых систем.

Реклама

Книга: визуальные заметки, Майк Роуди

 

clip_image002После того, как я прошёл курс IQDoodles, нужно было двигаться дальше: научиться использовать новое умение не только для иллюстрации блога, но найти ему и другие применения. Про скрайбинг я уже писал, но пока мне некуда его применить. Следующая возможность улучшить свою жизнь с помощью визуализации – визуальные заметки.

Книжка из заголовка прекрасно готовит и мотивирует к этому занятию. По крайней мере, саму книжку я стал документировать не в виде мыслесхемы, как привык, а в виде заметок с рисунками. Да и на встрече с автором комиксов komikaki тоже удалось сделать несколько зарисовок.

Чуть ниже пара примеров, в которых можно хоть немного разобрать почерк.

А пока немного полезностей из книги для затравки:

·         Майк рекомендует делать заметки ручкой. Карандашом, по его мнению, получается хуже: вместо отображения сути начинаешь наводить красивость;

·         Нужно обобщать, чтобы успеть записать/зарисовать самое важное. Но при этом теряются детали;

·         Самое важное всё-таки творится не на твоём блокноте, а на мероприятии. Фокусируйся на том, что фиксируешь, не на процессе фиксации. Иначе ничего не получится;

·         Структура и контент важнее красивых рисунков;

Какие-то сухие заметки получились. Книга сильно лучше. Рекомендую книжку прочитать, если кажется, что такой способ исполнения заметок может пригодиться и понравиться.

Ну и некоторые из зарисовок (кликабельно).

майк роуди_виз. заметки page6

майк роуди_виз. заметки page9

майк роуди_виз. заметки page10

Легко ли читать: Да, конечно. Книжка на 80% состоит из рисунков, а как ещё? =)

clip_image001[4]

Полезность: Выписал для себя много инструментария, даже начал пробовать. Пожалуй, выше среднего.

clip_image002[4]

 

@innubis и секреты iPad’

в поисках лета Final

Случайно получил пару недель назад приглашение на пилотный запуск нового курса Кирилла Анастасина, одного из людей, творчество которых и меня гонит иной раз взять и попробовать нарисовать что-нибудь. Курс будет посвящён работе тренера/преподавателя/докладчика с iPad Pro, которого у меня нет и нескоро будет, но как я и прозревал, записываясь на встречу, иногда планшет, это просто планшет, и важно лишь, как ты его используешь и есть ли нужное приложение под твою платформу.

Кирилл просил не особо афишировать содержимое курса пока, так что фиг вам, а не подробности. Но как минимум пару приёмов и новых сценариев использования планшета я для себя вытащил. К примеру, использование некоторых приложений нестандартное: Кирилл использует Trello для планирования курсов. А paper by 53 можно использовать в брейнштормах, или вообще как замену флипчарту. Когда вдруг приобрету или получу в дар iPad Pro, буду использовать. Или найду замену для себя.

Ну и посмотрел, как создаются комикаки:

А вот результат:

WP_20170302_19_52_57_Pro

Чтобы не быть на этом фоне совсем уж бездарью, сам придумал и нарисовал комикс, с которого начинается статья. Назвал “В поисках лета” Winking smile

Книга: The Phoenix Project

clip_image002[7]Итак, я добрался до Святая Святых девопса – бЫзнес-романа The Phoenix Project. Снова прозреваю, что кроме меня его уже все читали. Так что я снова коротенько по задевшим лично меня моментам, равно как и по непонятным или смешным.

Интересный подход: выкатывать, но не включать функционал. Тогда код уже на проде и всё работает, в общем-то. Или включаем, но не для всех пользователей или сценариев. Или только для тестирования. Увы, не для всех типов ПО подходит. Но нужно использовать, где это возможно.

Есть три путя:

1)      Никакой локальной оптимизации, никакого «с моей стороны пуля вылетела». Делаем мелкими партиями, никогда не передаём дефектный код дальше. Инструментарий:

a.       Continuous build, integration and deployment.

b.       Создание окружений по запросу.

c.       Ограничение WIP.

d.       Построение safe systems and organizations that are safe to change. Вот этот кусок несколько абстрактен. Прозреваю, что пойму, когда настанет пора (или когда прочитаю DevOps Handbook J).

2)      Построение обратной связи. Не очень понятно, как мне это делать в своей ситуации. Тоже нужно разбираться.

a.       Остановка production line когда тесты и билды фейлятся. Здесь всё просто относительно, если мы качественно разберёмся с пп.1 и 2d.

b.       Постоянно улучшать работу даже в ущерб повседневной работе. Всё понятно, но нужно где-то взять политической воли. Есть взаймы у кого-нибудь? =)

c.       Создание быстрых автотестов, подтверждающих, что код всегда готов к деплою.

d.       Создание общих целей между Dev & Ops.

e.       Всепроникающая телеметрия, показывающая, всё ли хорошо. Тут печаль, в наших обстоятельствах это будет дорого, долго и сложно. Но подвижки есть.

3)      Создание культуры, которая пестует постоянные эксперименты и учёбу на ошибках и успехах.

a.       Создание культуры инноваций и принятия риска. Вот тут ещё учиться и учиться. Мне.

b.       Выделение хотя бы 20% времени на постоянное улучшение. Как показал эксперимент, тупо выделение этого времени не работает. Нужно предыдущий подпункт корректировать, да и ещё чего-то может не хватать.

Хотя везде идёт рефреном «break the silos», всё равно эта история – про повышение ответственности той части команды, которая пишет код продуктов. Автоматизация релизов просто не оставляет других шансов. Если ручное развёртывание Ops’ами релизов ещё как-то нивелирует последствия плохого кода или тестирования (админ может руками что-то откатить или допилить на лету вместе с разработчиком), то полная автоматизация должна это сделать сама. Нет, понятно, что разбудить админа, чтобы он починил, всё равно можно, но это дополнительное время простоя. Немного нивелируется это тем, что теперь ответственность Ops за инфраструктуру именно доставки кода и окружений также становится очень высокой. На самом деле, надёжность этого куска должна быть, кажется, запредельной. Чуть ли не выше доступности самих продуктов.

Автоматизировать всё нужно даже не для сокращения издержек, а для того, чтобы разрабы могли сами получать окружение, похожее на продуктив. Чтобы прохождение тестов на stage-среде действительно было маркой качества: развёртывание в бой не сорвётся. И чтобы переиспользовать эту экспертизу для разных команд разработки.

Вопросы:

По книге основные потоки работы это: бизнес-проекты, технические проекты, изменения, починка/тушение пожаров. Но как-то до меня из книжки не дошло:

1)      Почему разделяются бизнес и технические проекты? Обновление почтовой системы – технический проект? Но там есть функционал для бизнеса, допустим. В общем, мне это деление кажется несколько условным.

2)      Проекты состоят из изменений, почему мы их, опять же, разделили?

Из занятного: снова появляется Русская Мафия, которой с придыханием нужно продать данные ваших клиентов, украденные хакерами. Всё-таки к Медведю с Балалайкой мы, похоже, добавляем ещё один национальный бренд. =)

Легко ли читать: Да, легко и интересно. Всё-таки, это больше художка, и не так, чтобы плохо написанная.

clip_image004

Полезность: выше средней. Прорыва у меня пока нет, всех ответов нет. Нужно следующее читать. Но и зря потраченным временем это не назвать – польза однозначно есть.

clip_image006

 

Как больше успевать?

Изначально опубликовано на HH.ru

Основные комментарии оттуда же (дословно):

“Какая галимотья!”

“Сама статья, как папка «Разобрать»”

“тайм-менеджмент не поможет”

Так что интересно, можете быть уверены Smile 

imageСколько обещаний вы даете себе на 2017 год? Заниматься спортом, проводить больше времени с семьей, читать больше книг? У меня нет статистики, но, полагаю, не ошибусь, если скажу: многие из «сорвавшихся» жалуются на «нехватку времени», как причину того, что их новогоднее обещание так и осталось обещанием.

Они говорят: «У меня очень мало времени на …». Звучит это убедительно, ведь для того, чтобы заниматься спортом, нужно время. Даже задача «провести время с семьёй» прозрачно на это намекает.

Практически любое обещание потребует, чтобы мы уделили ему свои драгоценные секунды, часы и дни. Что мешает это сделать? У нас:

1)      мало времени

2)      много дел

Управлять временем мы не можем: его всегда 24 часа в сутки, и 7 суток в неделе. Но мы можем управлять тем, как и на что своё время тратим. Предлагаю на этом и сосредоточиться.

Что нужно сделать, чтобы успевать больше? Не обдумывать задачи больше одного раза, и стараться делать их в потоке, не отвлекаясь.

Перестать тратить силы на повторные решения

Каждая мысль, это принятие решения. Вы подумали про чужую книгу, которая лежит на столе, и приняли решение не отдавать её прямо сейчас. За день эта мысль несколько раз повторится в голове. Вспомнили, что нужно купить зубную щётку, но решили, что среди рабочего дня идти в магазин – моветон. «Вечером после работы и куплю», — подумали вы ещё три раза. И так далее. Кстати говоря, всплывающие уведомления от почты или мессенджеров (равно как и звуки от них), открытые вкладки браузера и 15 открытых приложений на рабочем столе – каждый раз, когда мы смотрим на эти объекты, мы снова принимаем решение – сейчас посмотреть, что там в письме, или потом. «Вот эта вот вкладка в браузере, она мне завтра пригодится точно, сейчас её закрывать не стоит».

Любое решение истощает способность активно мыслить. Это важно понимать, потому что активно мыслить мы можем не более нескольких часов в день. Поэтому решения нужно принимать однажды и возвращаться к ним, только когда мы эти решения готовы исполнить. И для этого нужно воспользоваться следующими советами.

Выгружать все задачи из головы.

Твоя голова – самый паршивый офис

Дэвид Аллен

imageДержать все свои дела в голове, это худшее, для чего её может использовать человечество. Некоторые исследователи считают, что мы способны обрабатывать не более трёх-пяти идей одновременно. Представим:

·         прямо сейчас нужно написать отчёт;

·         после работы зайти в магазин;

·         оплатить интернет;

·         оплатить страховку для машины.

И тут в голову в третий раз приходит «новая» мысль – «не забыть в магазине купить молоко!!!». В этот момент пропадает концентрация на одной из предыдущих идей. Я обычно «роняю» то, чем нужно заниматься прямо сейчас – отчёт. Мало того – каждый раз, когда мы так отвлекаемся, мы теряем контекст. И тратим на его восстановление ресурс, предназначенный для того, чтобы работать и думать. Вместо отчёта наши силы уходят на повторное принятие решения купить молоко вечером или на выходных.

Поэтому все задачи должны лежать там, где им место – в списке задач.

Перестать накапливать задачи во «входящих»

Вопрос: Какую самую большую ошибку может

совершить владелец бесконечного диска?

Ответ: создать на нём папку «Разобрать!»

Три блокнота, четыре почтовых ящика, лоток для бумаг на рабочем месте, кошелёк, тумбочка возле рабочего стола, фото на телефоне, файлы на рабочем столе ноутбука: это список моих входящих. Что такое входящие? Это места, где накапливается все, что может превратиться в задачи.

Как и в папках «Разобрать», «Sort», «Другое», нельзя позволять накапливаться объектам во входящих. Иначе их масса включит механизмы прокрастинации и задачи, в лучшем случае, протухают. А в худшем приходят уже в виде срочных и неприятных, «доказывая», что ваша система работы с задачами никуда не годится.

Вести все задачи в одном списке

Не нужно делать для каждого вида деятельности отдельный список задач. По крайней мере на первом этапе вживания в новое, производительное «я». Я серьёзно.

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

В этом правиле могут быть исключения, если вы точно знаете, что делаете. Вот когда это возможно:

1)      дела из списков никогда не пересекаются и на каждый список есть выделенное время. К примеру, есть домашний и рабочий список: мы не делаем домашние дела на работе, а, уходя с работы, вычёркиваем её из своей жизни.

2)      Если это вынужденная мера: например, политика безопасности компании запрещает смешивать списки. Придётся мириться с возможными последствиями и контролировать, чтобы такого не происходило , чтобы этого не происходило.

Главное – помнить: чем больше у нас источников задач, тем больше вероятность, что часть дел никогда не выполнится.

Записывать задачи так, как будто выполнять их предстоит роботам

«Зимняя резина» — это достаточно понятная задача?

Строго говоря, нет. Даже «Зимняя резина, @#$!!!» — не задача. Задача отвечает на вопрос, что нужно сделать, и описывает конкретное действие, которое нашему роботу предстоит сделать. Поэтому, скорее всего, задача будет звучать так: «позвонить по телефону xxxxxxx и договориться о замене резины». Потом будут задачи: «заехать за зимней резиной в гараж» и «поехать в ХХХ, чтобы заменить резину (не забыть положить резину в машину!)».

Такие действия легко выполняются без включения мозга. Они не требуют принятия решения и потому позволяют выполнять такие задачи чуть ли не дюжинами, не растрачивая нашу энергию.

Не нужно полностью описывать все действия, если понятно, как их выполнять. «Осторожно перемещайте пылесос так, чтобы он собрал весь мусор» — излишне. Хватит «пропылесосьте во всех комнатах». Но должно быть понятно, что нужно сделано.

«Прочитать все книги в Ленинской библиотеке» — это не задача, а проект. В библиотеке огромное количество томов. Работа будет очень громоздкой, поэтому формулировка её в таком виде будет вызывать отторжение.

«Изучить английский» — и вовсе покушение на изменение образа жизни. Ведь нельзя идеально выучить язык за 10, 50 или 300 занятий. Для этого нужно изменять свою жизнь, каждую неделю уделяя время чтению, аудированию и другим занятиям.

Ещё раз:

·         задача должна рассказывать, что нужно сделать (для этого там нужно полное предложение: подлежащее, сказуемое и прочие члены. См. пример выше);

·         задача должна выполняться с минимальным напряжением. Она должна быть понятна даже роботу, для чего её формулировка должна совпадать с первым шагом, необходимым для продвижения к цели;

·         задачи, которые слишком крупные и являются, по существу, проектами (прочитать БСЭ) или новым образом жизни (стать здоровым и стройным), нужно дробить на более мелкие и понятные: прочитать 10 страниц 15го тома (или почитать БСЭ полчаса) и сделать становую 80кг*8, 4 подхода.

Кстати, вы заметили небольшой довесок в конце одной из задач? Я про «не забыть положить резину в машину!». Это элемент чек-листа. И я призываю их использовать.

Использовать чек-листы

Все маркетинговые уловки бесполезны

против сытого мужчины со списком покупок.

В жизни каждого человека есть повторяющиеся сценарии: каждый год вы едете в отпуск, готовите годовой отчет, собираете детей в школу. Да, отпуск в этом году может быть не на Бали, а под одеялом дома, но на работе при этом нужно сделать каждый раз одни и те же действия. Я пользуюсь таким списком уже несколько лет и даже поделился им с другими людьми в приложении MaxDone. Кроме того, у меня есть списки для сборов, что сохраняет нервы при каждом отъезде.

Кстати, список можно «оформить» по-другому. В каждую поездку я беру с собой некий набор, который мне в других обстоятельствах не понадобится: дорожную подушку, переходники для электрических розеток и прочее. Все эти вещи я просто складываю в чемодан, и храню там. Для того, чтобы их взять, мне вообще не нужно использовать мышление – они просто лежат там, где это мне понадобится. Достаточно спинного мозга.

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

«7.        дом

·         отопление

·         кондиционирование

·         водопровод/канализация

·         ремонт

·         электричество

·         мебель

·         коммунальные службы

·         платежи

·         кухня/оборудование кухни

·         санузел

·         места для глобальной уборки

·         кладовка

·         антресоль»

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

Список же «еженедельного обзора» служит нашей следующей задаче.

Научиться доверять своему списку задач

Это самое сложное. Я сам несколько раз встречался с этой проблемой, пока не научился, и замечал её у других: список задач есть, но задачи в него только записываются, и редко выполняются. Или задачи выполняются без обращения к списку, мимо него.

В итоге мозг соображает, что задачи он записал, а вот выгружать их пока не стоит, потому что тогда они никогда не выполнятся.

По моему опыту для доверия к системе нужно научиться следующему:

1)      заносить любые задачи в список;

2)      выполнять только те задачи, которые есть в списке;

3)      регулярно проводить еженедельный обзор системы. 

Еженедельный обзор

В его рамках нужно

1)      полностью очистить все входящие (лучше это делать чаще, но раз в неделю почти необходимо);

2)      пройтись по всем задачам в поиске тех, которые прокрастинируются, случайно выполнены, но не отмечены такими, плохо сформулированы или ещё каким-то способом загрязняют наш список задач;

3)      Просмотреть дела на следующую неделю и спланировать те задачи, которые должны быть выполнены в этот период.

Не сдаваться

Никогда. Любая система личной эффективности иногда приходит в негодность. Что бы ни было причиной – два списка задач из необходимости, изменение служебных обязанностей, аврал из любых падений нужно извлекать уроки, придумывать новый инструмент, чтобы избежать подобных проблем в будущем и снова учиться выполнять задачи, а не печалиться о них.

Что дальше?

Всё, что мы выше обсудили, помогает делать больше. Давайте посмотрим:

1)      Мы не «повторяем дважды». Время на это больше не тратится. Но даже сохранённое время меркнет перед тем, сколько сил нам это экономит.

Понятно, что этого лишь общие советы, из которых достаточно сложно вырастить свою систему без помощи. К счастью, сейчас есть множество методик, которые разбирают в подробностях, как и что нужно делать. Моя любимая – методика Макса Дорофеева. Но вы можете использовать и другие проверенные методы. Главное – двигаться вперёд. Успехов!

Вечное сияние чистого аврала

clip_image002[4]Кому-то это может показаться странным, но я умудрился немного расслабиться перед Новым Годом (несмотря на то, что я повторял за кем-то, что НГ воспринимается как-то больше дедлайном, чем датой). И в тот момент, когда я слегка расслабился, внезапно, придумал ещё одну потенциальную причину, по которой мы любим работать под жёсткими дедлайнами.

Что ты имеешь в виду «я этого не люблю»? Давай вспомним последнее «свистать всех наверх». Не было ли ощущения, что ты легко можешь не спать несколько ночей кряду? Не было ли это хотя бы отчасти не только страшно, но и весело – работать над проблемой таким образом? Если да, то в чём причина? Не в Паническом же Монстре. Да, я прекрасно помню, что работать в таком стрессе, это… Ну, в общем, это стресс. И всё же, было в этом и что-то привлекательное.

Ладно, если нет воспоминаний о том, «как было круто сделать пятидневную работу за пару часов», то нет смысла читать дальше, наверное. Для остальных у меня есть идея (и никаких доказательств) на «подумать»: что, если нам нравится работать в дедлайнах из-за ясности ситуации? Смотри, когда ты только что практически просрал все сроки, обычно остаётся только одна задача. Само собой, никто не убрал остальные задачи, но, чёрт возьми, у меня есть САМАЯ ВАЖНАЯ ЗАДАЧА! Она же, обычно, и самая понятная, потому что вместо «я должен обдумать эту задачу и понять, как её делать», в этот момент ты её просто берёшь и начинаешь делать (откладывать-то уже некуда).

Короче, на какое-то время можно быть уверенным, что у нас есть ровно одно дело, которому мы должны уделять внимание. Само собой, всё остальное нас рано или поздно нагонит (кстати, неа, не всё J), но прямо здесь и сейчас нам не нужно ничего выбирать, мы просто должны фигачить. В дополнение, намного проще работать, когда задача только одна: ничто не отвлекает, уровень концентрации зашкаливает, попасть в состояние потока очень легко (потому что всё получается при таком режиме и вообще от этого всего прёт). Полагаю, что это нас делает немного счастливее.  

К сожалению, «делает счастливее» не значит в этом случае «заставляет работать лучше»: если задача обычно выполняется 5 дней, достижение результата за одну ночь вряд ли даст наилучший результат. Часто мы лажаемся или стандарт результата ниже обычного. Кроме того, как бы ни был силён эффект адреналина и Панического монстра, мы устаём во время таких приключений. Особенно, если неправильно себя ведём во время авралов и не восстанавливаем свои ресурсы.

Всяко, предлагаю держать в голове, что это, возможно, одна из причин, по которой мы любим прогаженные дедлайны. Знание этого может склонить сознание в сторону меньшей прокрастинации задач.

P.S. Если кто-то знает исследования, поддерживающие идею – делитесь. Хочу почитать.

Книга: Мифический человеко-месяц, Фредерик Брукс.

Image result for мифический человеко-месяцА давайте я вместо традиционных предновогодних вещей попробую нанести ещё немного пользы хотя бы себе. Прочитал я тут недавно ещё одну книжку (на самом деле, две, но о второй уже в следующем году), полную безысходности. Книга повествует нам о проблемах разработки ПО. Причём, первое издание случилось в 1975 году. Да – более 40 лет назад. Да, тогда тоже разрабатывали ПО.

Самое важное ощущение от книги:

Чёрт. За 40 лет в индустрии ничего не поменялось!

Проблемы, одолевавшие автора почти полвека назад – остались теми же. Нет, некоторые мысли, высказывавшиеся Фредериком, с тех пор были значительно доработаны, но практически все решения проблем, о которых он говорил, так и остались уделом единиц, а в основном, никаких общих решений, ставших бы спасением, и нет.

К примеру, так и нет возможности точно предсказать, когда же будет завершён проект. Да, я в курсе про ToC, lean, agile и прочие замечательные слова. Но за меня говорят более 60% проваленных проектов в ИТ. Возможно, кто-то и может предсказать, когда закончится тот или иной проект, сколько денег он съест, и что же при этом получится, но я видел таких людей пока только в книжках (если кто видел лично – познакомьте, я хочу научиться =)).

И, повторюсь, многое, написанное этим замечательным инженером 40 лет назад, я вижу в той литературе, которая актуальна для меня на сегодняшний день:

1)      Важность постоянной готовности выбросить результаты экспериментов. Делаем не на века, а чтобы проверить: будет ли работать вообще. Мне, как представителю operations с почти 15тилетним опытом это почти невозможно сделать. Это то, чему нас учит куча литературы по упомянутым выше идеям и способам работать.

2)      Идеи о средах тестирования, наборах данных для них и соответствия их друг другу я вижу в подходах DevOps.

Впрочем, есть и улучшения. Взгляните, что было написано 20 лет назад (я читал издание 1995 года):

…дают свидетельства в пользу того, что квант изменений должен быть либо очень большим и редким, либо очень маленьким и частым. [14] Последняя стратегия, согласно их модели, больше подвержена неустойчивости. Мой опыт это подтверждает: я никогда не рискну использовать ее на практике.

Сейчас все, кто пытаются ускорить разработку и повысить её качество, говорят об обратном.

В общем, книжка весьма занимательна. Некоторые моменты пропускал, потому что архитектурные детали разработки OS/360 мне уже не сильно интересны.

Легко ли читать: средне. Мешают части про перфокарты. =)

clip_image002[4]

Полезность: ниже среднего. Книга-безысходность, всё-таки =) Сейчас есть более проработанные учения.

clip_image004[4]

Ах, да. С Новым Годом!