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

Как часто мы сталкиваемся с ситуациями, когда, встретив полезную информацию, мы забываем о ней так и не успев применить на практике?

Однажды, читая главу в книге Дона Нормана “Дизайн привычных вещей” о чек листах, я осознал, что просто создание заметок о лучших практиках, применяемых в процессе работы над проектом, и их редкий обзор — не самая эффективная стратегия. Поэтому ниже приведены лучшие заметки из многочисленных источников, которые мне удалось собрать за последние несколько лет, сгруппированные в виде чек-листов на различные темы.

Для кого эта статья?

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

Многие из этих советов в том или ином виде встречались мне неоднократно в различных источниках.

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

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

Содержание

Работа с идеями
Дизайн
Архитектура
Работа над проектом
Настройка рабочих процессов
Безопасность

Работа с идеями

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

Дизайн

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

Базовые идеи

Помните, что несмотря на быстрое изменение технологий, человеческое поведение меняется не так быстро. И то, как мы действовали 20 лет назад, все еще актуально. Посмотрите, например, свежий отчет how-people-read-online.
Используйте дизайн вместо функциональных спецификаций, которые лишь создают иллюзию согласия. Люди, читая один текст, понимают его по-разному.
Не обращайте внимания на детали в начале процесса. Двигайся от большого к малому. Начинайте с дизайна и макетов. Их гораздо легче менять чем код. В дизайне начинайте с эпицентра.
Возможности и антивозможности вещей должны быть очевидными.
Когда возможности и антивозможности сложно обнаружить, мы должны дополнить предмет подсказками.
Связанные друг с другом элементы должны быть расположены вместе. Помещайте регуляторы и важную информацию именно там, где они требуются.
Обратная связь должна быть мгновенной: задержка даже на десятую долю секунды может заставить человека нервничать. Если задержка длится слишком долго, люди часто сдаются и идут заниматься чем-то другим.
Если обратной связи слишком много, это может раздражать даже больше, чем если её слишком мало. Если мы слышим слишком много сообщений, мы начинаем игнорировать их все или отключаем всё что можно. И это значит, что мы, скорее всего, пропустим действительно важные сообщения.
Уберите все сообщения об ошибках. Вместо этого обеспечьте пользователям помощь и руководство. Сделайте так, чтобы можно было исправить проблему сразу же с помощью всплывающих подсказок
Не рассчитывайте, что люди сохранят что-то в краткосрочной памяти. Часто, когда что-то идет не так, компьютерные системы показывают сообщение с важной информацией, которое исчезает с экрана в тот самый момент, когда человек хочет его прочитать.
Стандартизация — фундаментальный принцип отчаявшихся: когда любое другое решение кажется невозможным, просто проектируй всё одинаково, чтобы люди могли выучить что-то один раз и навсегда. Например:
- Расположение лого в левом верхнем углу.
- Знакомые иконки для корзины, видео и т.п.
Избегайте алгоритмов, которые начинаются одинаково, а потом становятся отличными друг от друга. Чем более опытным будет работник, тем с большей вероятностью он станет жертвой такого промаха. Всегда, когда это возможно, алгоритмы должны быть прописаны так, чтобы они отличались друг от друга с самого начала.
Способы снижения ошибок:
- Сделать более заметным тот элемент, с которым работает пользователь. То есть изменить внешний вид самого объекта, над которым совершается действие, чтобы он был более заметным: увеличить его или, может быть, изменить цвет.
- Сделать так, чтобы операцию можно было отменить.
- Добавить проверки на разумность.
На этапе тестирования достаточно опросить 5 независимых человек/групп, чтобы получить адекватный отзыв. Можно начать с других членов команды. Используйте при тестировании открытые вопросы.
Не собирайте лишнюю информацию, которую не используете сейчас.
Люди часто выбирают первую удовлетворительную опцию, а не ищут лучшую. Наши представления о том, как работают вещи часто неверны, поэтому, когда мы разбираемся как, что-то работает, мы не ищем нового решения, даже если текущее плохое.
Крадите как художник. Используйте доступные площадки для вдохновения: (dribble, pinterest, pttrns

Технические советы и тонкости

Учитывайте обычное, пустое и ошибочное состояние в дизайне. Пустое состояние производит первое впечатление, поэтому очень важно.
Реализуйте светлую и темную тему.
Не задавайте слишком строгих ограничений на ввод полей формы. Особенно на имена. По возможности оставьте пользователю право определить, как пишется его имя. И не наказывайте за несоблюдение выдуманных правил и ограничений (форматирование полей и т.п.). Форматируйте по возможности автоматически.
Кликабельные вещи должны быть очевидными. Не используйте один и тот же цвет для ссылок или кнопок и некликабельных заголовков. Делайте видимым различие между посещенными и не посещенными ссылками.
Используйте ясные заголовки и подзаголовки для разбиения контента на секции, чтобы пользователи могли сканировать контент для поиска нужной информации.
Не позволяйте заголовкам плавать между двумя блоками текста, он должен быть явно ближе к своему блоку.
Сохраняйте параграфы короткими. Сократите тексты, убрав все незначащие слова и предложения. Используйте простой язык.
Используйте списки. Выделяйте ключевые слова. Это позволит глазу фокусироваться на наиболее важной информации.
Возможно, вам не нужна большая картинка на главной, когда люди понимают, о чем сайт, она их раздражает размерами. Те, кто вас уже знает, не нуждаются в ней.
Свет падает с неба. Тени — это бесценные подсказки в сообщении человеческому мозгу, на какие элементы пользовательского интерфейса мы смотрим.
Сперва черное и белое. Проектирование в оттенках серого перед добавлением цвета упрощает дизайн и заставляет вас сосредоточиться на расстояниях и расположении элементов.
Добавьте больше свободного пространства. Удвойте расстояния между элементами.
Используйте качественные шрифты.
Учитывайте вопросы доступности. В текущей ситуации огромное количество людей, не очень хорошо знакомых с компьютерами вынуждены их использовать в значительно больших объемах, чем ранее.

Доступность

Увеличьте текст до 200% и проверьте как выглядит ваш продукт.
Проверьте контрастность. Браузеры умеют подсказывать вам о недостаточной контрастности. Также можно включить режим повышенной контрастности в ОС.
Добавьте alt атрибуты.
Правильно используйте заголовки. Не перепрыгивайте через размеры.
Проверьте наличие label для полей форм.
Отслеживайте доступность контента с клавиатуры.

Более подробно можно посмотреть здесь:

a11yproject.com
wai-aria-practices

Архитектура

Если вы думаете, что хорошая архитектура стоит дорого, попробуйте плохую архитектуру.
Брайан Фут и Джозеф Йодер

Не делайте сложную архитектуру в новых проектах, т.к. это не только долго и дорого, но и, если ваша первоначальная идея и планы оказываются не востребованы, вам сложно быстро скорректировать идею и поменять продукт.
Выработайте язык, основанный на модели продукта для общения программистов со специалистами.
Разбивайте программу на уровни и изолируйте их друг от друга. Знания предметной области должны быть только в одном уровне. Графический интерфейс не имеет значения для бизнес-правил, поэтому между ними следует провести границу. База данных не имеет значения для графического интерфейса, поэтому между ними следует провести границу. База данных не имеет значения для бизнес-правил, поэтому между ними следует провести границу.
- База данных — это не модель данных. База данных — это часть программного обеспечения. База данных — это утилита, обеспечивающая доступ к данным. С архитектурной точки зрения эта утилита не имеет никакого значения, это низкоуровневая деталь — механизм.
- Пользовательский интерфейс — это деталь. Веб — это пользовательский интерфейс. То есть Веб — это деталь. И как архитектор вы должны размещать детали, как эта, за границами, отделяющими их от основной бизнес-логики.
Следите за тем, чтобы между модулями была низкая связность, в то время как внутри модуля связность может быть выше.
Если в процессе разработки программы выясняется, что специалисты не понимают какие-то технические детали с упрощённых схем или вы не понимаете описания специалистов, то это сигнал, что скорее всего у вас пробелы знаний в предметной области и архитектура будет неудачной, если не внести изменения.
Давайте хорошие имена классам и методам. Если для понимания работы объекта нужно изучать его реализацию, то теряется смысл инкапсуляции.
Вдохновляйтесь математикой. Вводите математические операции для объектов. Это может улучшить архитектуру и принести красоту в код.
Придерживайтесь минимализма.
Три шага в создании ПО от Кента Бека:
- Сначала заставьте его работать. Вы останетесь не у дел, если он не работает.
- Затем перепишите его правильно. Реорганизуйте код, чтобы вы и другие смогли понимать и развивать его, когда потребуется что-то изменить или понять.
- Затем заставьте его работать быстро. Реорганизуйте код, чтобы добиться "необходимой" производительности.

Работа над проектом

Если вы не переживаете, стоит забеспокоиться, а если переживаете, стоит прекратить.
Рэй Далио

Используйте метрики для отслеживания развития продукта. Важно найти баланс по количеству метрик. Их не должно быть много, чтобы это было недорого и быстро, но при этом достаточно, чтобы видеть проблемы. 3-4 метрик может быть достаточно. Если ваша метрика близка к 100%, возможно, ее стоит поменять. Но не забывайте о коммуникациях, метрики — это лишь цифры.
Учитывайте, что при отсутствии данных люди отвечают иначе, чем при предоставлении бесполезных данных. Когда конкретных данных нет, априорная вероятность используется правильно; когда есть бесполезные данные, априорная вероятность игнорируется.
В случае возникновения проблем, в попытке понять причину воспользуйтесь технику "5 почему". Т.е. следует задавать вопрос почему, постоянно углубляясь в суть проблемы, чтобы найти истинные причины. Определите, кто несет ответственность за результат. Если результат плохой, обусловлен ли он недостатком нужных навыков у ответственного лица или ошибками в плане действий?
Вы можете управлять проектом с помощью стоимости, времени, качества и масштаба. Все должны видеть и понимать эти переменные и их связь для правильного принятия решений. Наиболее оптимально управлять переменными за счёт масштаба. Поэтому придерживайтесь планов по бюджету и времени, но жертвуйте масштабом. Отсеките половину идей, после этого посмотрите на оставшиеся и повторите. Чем вы легче, тем вам проще меняться.
Начинайте с маленькими бюджетами — это фокусирует на наиболее важных задачах, приводит к изобретательности.
Путешествуйте на легке, это позволяет быстро адаптироваться. Старайтесь не привязываться к вендорам, проприетарным форматам, жестко зафиксированным дорожным картам.
Не решайте несуществующих проблем. Для каждой новой задачи старайтесь найти способ более быстрой и дешёвой реализации. Придерживайтесь простоты: завтра может никогда не наступить или к тому времени, когда оно наступит, мы будем знать лучшие способы решения проблемы. Не платите за гибкость, которая вам не нужна.
Пишите тесты и сохраняйте при этом код максимально простым. Благодаря этому вы можете снизить стоимость изменений, избегать оверинженеринга и фокусироваться на текущих проблемах. Тесты дают вам мгновенную обратную связь.
Подумайте о найме тестировщиков. Стоимость тестеровщиков значительно ниже, чем разработчиков.
Научитесь говорить нет идеям. Учитывайте скрытую стоимость реализации.
Не ограничивайте сильно людей процессами, предоставьте им придумать как решить задачу самостоятельно. Позвольте им ошибаться. Вы можете даже заложить дешевые ошибки в бюджет. Важно при этом делать разбор этих ошибок, чтобы не повторять их слишком часто. В большинстве случаев люди хотят делать хорошую работу, задача менеджера помочь им в этом. Ошибки — естественная часть процесса развития. Каждый имеет право и обязан попытаться дойти до сути важных вещей.
Избегайте настроек, они имеют свою цену реализации.
Двигайтесь маленькими шагами. Используйте итерационный процесс для улучшения продукта. Тестируйте свои решения как можно быстрее, не копите до финального релиза. Прототип, удовлетворяющий не всем условиям, уже может быть полезен, для отработки его со специалистами или другими командами.
Учитесь и заботьтесь о том, чтобы команда тоже училась. Несмотря на то, что со временем человек может достигнуть высокого уровня мастерства в каком-то деле, само дело для него легче не становится: олимпийский чемпион сталкивается в своем виде спорта с не менее сложными задачами, чем новичок. Не ожидайте, что сотрудники сами определят свои «слепые зоны» и компенсируют их.
Играйте чтобы победить, а не чтобы не потерять. Не нужно прикрывать бумажками и планами все, чтобы потом сказать, что это не ваша вина.
Берите ответственность за свои действия.
40-часовая рабочая неделя (±5 часов) позволяет быть эффективным и сконцентрированным. Не допускайте переработок две недели подряд.
Помните о балансе бизнеса и разработки. Каждый должен отвечать за свою часть и быть доступен для другой стороны.
Планируйте в деталях только текущий релиз или итерацию. Чем дольше вы откладываете планирование, тем больше будет у вас данных и тем точнее вы сможете просчитать следующие шаги.
Время не бывает отрицательной величиной, поэтому ошибки времени всегда скапливаются справа. В этом заключается асимметрия. Поэтому мы часто ошибаемся со временем при планировании.
Срочные вопросы не важнее стратегических. Иногда меньше значит больше и часто стоит отбрасывать лишнюю и несущественную информацию и фокусироваться на главном. Помните о принципе Парето 20/80.
Срочность одна из основных причин нашего искаженного восприятия мира. Когда мы под прессом срочности, мы принимаем плохие аналитические решения. Всегда нужно посмотреть и измерить данные.
Issue log может быть хорошим инструментом для компании: сотрудники записывают туда все возникающие проблемы, уровень важности и ответственного, это помогает понять причины.
Боль + анализ = прогресс. Принимайте жесткость, идущую из лучших побуждений.
Один из самых важных навыков, который вам необходимо развить – это спрашивать совета у людей, компетентных в областях, в которых вы не сильны.
Высказывание предположений и вопросов не то же самое, что критика, поэтому не воспринимайте их таким образом.
Одновременно оценивайте скорость изменений, уровень, на котором находится цель и соотношение между ними. Если ситуация улучшается, но скорость изменений низкая, то за адекватное время цель не будет достигнута.
Чтобы принимать эффективные решения достаточно понимать большинство вещей на общем уровне.
Определяйте приоритеты, оценивая важность дополнительной информации по отношению к цене откладывания решения.
В первую очередь следует сделать то, что должны, а потом уже то, что нравится. Не отвлекайтесь на яркие безделушки, а также не забывайте за повседневными задачами о механизме в целом.
Есть вероятность, что не хватит времени на мелочи, но это лучше, чем, если его не хватит на важные вещи. Например, можете использовать матрицу Эйзенхауэра для расстановки приоритетов, разделив задачи на срочные и важные, несрочные и важные, неважные и срочные, неважные и несрочные.
Любую задачу следуют оценивать по вероятности ее успешного завершения и уровня ее приоритета.
Если вы организовали совещание, управляйте обсуждением.
Обозначайте зоны персональной ответственности при коллективном принятии решений. Обезличенное «мы» – явный сигнал, что человек пытается избежать признания ошибки.
Помните, что идея о том, что новый код будет лучше предыдущего может быть довольно абсурдной. Старый код уже использовался, он был протестирован и многие ошибки были исправлены. Помните, что, начиная сначала, вы выкидываете знания, которые были в проекте. Рассмотрите основные причины, по которым вы хотите переписать код и другие пути решения:
- Архитектурные проблемы — может быть решено внимательным рефакторингом, проверяемым всей командой.
- Проблемы со скоростью — часто 1% изменений может дать 99% прироста.
- Уродливый код — решается с помощью принятия стандартов форматирования, подключения автоформатирования, git-хуков и т.п.
Заведите трекер для багов. Старайтесь исправлять баги до написания нового кода.
Помните, что при демонстрации вашего продукта, важны пиксели, все будут сфокусированы на экране. Сделайте его максимально красивым. Но если можете, то отобразите в интерфейсе незавершенные части так, чтобы они выглядели незавершенными
- Если вы показываете не программисту экран, который выглядит на 100% завершенным, то он будет думать, что весь продукт почти готов
- Если вы показываете не программисту экран, который выглядит сильно хуже, чем предполагается в финальной версии, он будет думать, что весь продукт сильно хуже

Когнитивные искажения и ментальные модели

Существует огромное количество когнитивных искажений, а также ментальных моделей, в рамках которых мы действуем. Многие из них описаны у Канемана, Чалдини и т.д. Знание об их существовании поможет избежать некоторых ошибок в принятии решений или улучшить дизайн продуктов. Ниже приведена лишь малая часть тех, которые, на мой взгляд, наиболее соответствуют теме.

Избегайте эффекта привязки при оценке проектов. Когда вы оцениваете определенные шаги достаточно высоко, то может возникнуть угроза, что вероятность успеха по всему проекту будет завышена. Более строго описано у Канемана: полная вероятность конъюнктивного события (вытаскивание n раз подряд шарика) ниже вероятности каждого элементарного события, а полная вероятность дизъюнктивного события (вытаскивание хотя бы один раз шарика за серию испытаний) выше вероятности каждого элементарного события. Из-за эффекта привязки полная вероятность будет переоценена для конъюнктивных событий и недооценена — для дизъюнктивных. Общая тенденция к переоценке вероятности конъюнктивных событий ведет к неоправданному оптимизму при оценке вероятности того, что план принесет успех или проект будет закончен в срок.
Прижизненный эпикриз — метод борьбы с излишним оптимизмом (из пункта выше): "Мы внедрили план в существующем виде. Последствия оказались катастрофическими. Просим вас за 5–10 минут вкратце изложить историю катастрофы — как все произошло".
Ошибка безвозвратных затрат заставляет человека слишком долго терпеть нелюбимую работу, неудачный брак и бесперспективные проекты.
Эффект фрейминга — люди часто дают разные ответы на один и тот же вопрос в зависимости от рамок (формулировок). Этот эффект оказывает очень важное влияние на критичные вопросы, например, в странах, где человеку нужно отказаться от донорства, гораздо больше доноров, чем там, где ему нужно согласиться.

Коммуникации

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

Найм

Не нанимайте или нанимайте как можно позднее. Оцените, можете ли вы не делать что-то или сократить функциональность.
Если нанимаете, то предпочитаете меньшее количество более талантливых, чем большое количество посредственных. Это снизит издержки в коммуникации.
Группы от 3 до 5 человек на практике наиболее эффективны.
Как гласит закон Брукса, если к опаздывающему проекту добавить людей, он ещё больше задержится.
Подумайте, сотрудника с какими ценностями, способностями и навыками вы ищете. Порядок слов здесь имеет значение.
Исходите из предположения, что в большинстве своем люди не меняются.
Выбирайте дженералистов. Многозадачные члены команды позволяют быстрее адаптироваться к изменяющимся условиям.
При прочих равных условиях выбирайте хорошего писателя. Такие люди обычно яснее думают и лучше коммуницируют.
Думайте о своих командах как спортивный менеджер: ни один человек не обладает всеми качествами, необходимыми для успеха, но каждый должен быть в чем-то лучшим. Поэтому нужно проанализировать, где вы чаще терпите неудачи и усилить себя. Если набирать в команду людей с такими же сильными и слабыми сторонами как у лидера, то скорее это приведет к негативному результату. Разнообразие опыта среди кандидатов повышает шансы, что они привнесут новые идеи в проект.
Ищите людей, которые умеют завершать начатые проекты.
Обращайте внимание на дела, не на слова. Одним из показателей может быть наличие open-source проектов. Другими показателями могут быть:
- Страсть к программированию.
- Интерес к новым языкам и технологиям, так как может указывать на интерес к профессии в целом.
- Навыки работы с низкоуровневыми технологиями
В процессе интервью кандидат должен показать, что умеет писать код.
Один из вариантов проведения интервью:
- Вступление. Ваш короткий рассказ о себе, компании, позиции. Здесь же вы можете заверить кандидата, что вам важен процесс решения задач, а не фактические ответы.
- Задайте открытые вопросы о предыдущем опыте. Иногда углубляйтесь в детали. Можете попросить рассказать какие-нибудь сложные вещи простыми словами, чтобы определить, насколько реально кандидат понимает суть. Обращайте внимание на страсть, с которой кандидаты рассказывают об опыте.
- Задайте легкие задачи на программирование. Здесь стоит обратить внимание на скорость выполнения заданий. Это может быть хорошим показателем того, как человек будет решать реальные задачи впоследствии.
- Перейдите к более сложным вещам.
- Секция для вопросов от кандидата.

Настройка рабочих процессов

Используйте git-хуки, которые будут выполнять автоматические проверки кода, возможно, автоформатирование. Это упростит работу всех членов команды, поскольку значительную часть времени вы читаете код, а не пишете его. Также на этапе код-ревью это позволит фокусироваться на бизнес-логике, а не на стиле кодирования. Помимо этого, вы можете получить проверку качества кода или предупреждения о небезопасном коде. Можете присмотреться к lefthook и prettier (либо к любым другим похожим инструментам на ваш вкус) и, в зависимости от языка, к этим инструментам:
- CSS: stylelint
- JS: eslint
- Ruby: rubocop, breakman
- Elixir: mix format, credo, sobelow.
Внедрите практику обновления зависимостей раз в N дней. Это может быть раз в неделю или пара дней в месяц.
Используйте валидаторы:
- Доступность: a11y-checker
- Верстка HTML: validator.w3.org/nu
- Микроформаты: search.google.com/structured-data/testing-tool
Настройте процессы деплоя так, чтобы это происходило безболезненно для вас. Это позволит быстро тестировать продукт и получать быструю обратную связь. При этом в случае негативной обратной связи вы сможете быстро откатить изменения.
Автоматизируйте процессы (восстановление после сбоев, рутинные операции и т.п.), так как лично вы являетесь не самым надежным компонентом системы.

Безопасность

Обратите внимание на хранение чувствительных данных в репозитории. Не храните их в открытом виде. Иногда об этой проблеме может заботиться фреймворк, например Ruby On Rails или Phoenix. Либо вы можете выбрать другой подход, наподобие git-secret.
Позаботьтесь о базовой безопасности ваших серверов. Например, если у вас небольшое количество серверов, вы можете посмотреть советы в этой статье My first 10 minutes on a server и ее обсуждение на ycombinator. Либо вы можете пойти путем автоматизации развертывания серверов и создать/найти рецепты для вашей любимой системы, будь то ansible, chef или что-то другое.
Проверьте, что вы учли наиболее распространённые ошибки в сфере безопасности. Например, можно пройтись по списку owasp.org/www-project-top-ten и проверить, что:
- Вы позаботились об отсутствии инъекций в коде: SQL, NoSQL и т.п.
- Убедились, что аутентификация не сломана и работает корректно.
- Проверили отсутствие чувствительных данных и API в открытом доступе.
- Не допустили ошибок в конфигурации системы безопасности, например: поменяли пароли по умолчанию, корректно настроили файервол (особенно актуально для тех, кто использует docker).
- Позаботились об XSS.
- Настроили процессы обновления зависимостей в случае появления в них уязвимостей. Так, например, github присылает отчеты об уязвимостях в зависимостях для различных языков. Этот момент также может быть смягчен, если вы внедрили практику периодического обновления зависимостей, о которой говорилось выше.
- Настроили логирование и мониторинг ваших систем

Заключение

Надеюсь, вы найдете для себя полезную информацию, а также поделитесь своими мыслями и идеями.

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

Источники

Хотя я и не использовал здесь идей заметок из книги Тима Ферриса "Инструменты гигантов", но хочу указать её, как один из ресурсов, который вдохновил на написание данной статьи.

Domain-Driven Design: Tackling Complexity in the Heart of Software. Eric Evans.
Extreme Programming Explaned. Kent Beck.
Чистая архитектура. Искусство разработки программного обеспечения. Роберт Мартин.
Getting real. Basecamp.
Дизайн привычных вещей. Дон Норман.
Don't Make Me Think, Revisited: A Common Sense Approach to Web Usability. Steve Krug.
Factfulness. Hans Rosling.
Думай медленно… решай быстро. Даниэль Канеман.
Принципы. Рэй Далио.
Антихрупкость. Как извлечь выгоду из хаоса. Нассим Николас Талеб.
Evangelizing for the Lean Startup. Eric Ries.
7 Rules for Creating Gorgeous UI. Erik D. Kennedy.
Creativity: Generate Ideas in Greater Quantity and Quality. Stefan Mumaw.
Joel On Software
Kalzumeus Software
The Tim Ferriss Show

Инструменты гигантов: software development edition