Как сделать процесс запуска прогулкой по парку

1656557172 kak sdelat proczess zapuska progulkoj po parku

автор Давид Ю

Xlucy5Wi8oTxN6u-PkSUsZPpY5aqPo7f2ocG
Фото Джейми Тейлора на Unsplash

Было 2 часа ночи. Мой телефон все еще жужжал от разговоров разработчиков о том, как обрабатывать 404 страницы. Это было только начало…

Т минус три дня до запуска. Мы бегали, как курица с отрезанной головой. ?

Мне пришлось подумать, как избежать ощущения апокалипсиса, когда мы приблизимся к официальной дате запуска.

Как говорит закон Мерфи:

Все, что может пойти не так, пойдет неверно.

Как мы запускаем продукт и гарантируем, что что-то не пойдет не так (насколько мы можем)?

Ниже приведена бета-версия моей стратегии для следующего запуска.

Имейте содержимое на первую неделю

Когда вы сообщаете клиенту, что до даты запуска остался месяц, список данных и активов, необходимых для запуска, сохраняется в папке «Входящие» и появляется только за неделю до запуска. ?

В конце концов мы боремся за материалами из-за внезапных изменений изображений и текста — «мелочей».

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

Во время этой обратной связи теряется драгоценное время.

exFn60wYTY3iP0eLWC1CNil4lBRWCn8DyPew
«Группа людей обдумывает мозговой штурм за ноутбуком и листами бумаги», Штефан Штефанчик на Unsplash

Как побуждать клиента предоставить нужную вам информацию без грубости

  • Объясните, какое содержание является душой продукта. Без этого продукт является скелетом причудливой логики.
  • Будьте более активны, понимая, какие препятствия при покупке этих активов.
  • Запишите подробные характеристики изображения и копии: соотношение размеров изображения, желаемый тип файла, длина слова, желаемое семейство шрифтов.
  • Определите одного человека, которое отвечает за задание. Предложите помощь и помощь. Корректировку легче произвести на ранних этапах.

Что делать, если клиент скажет: «Успокойся… брат, мы на этом». И нет никаких четких действий, которые вы видите?

Вы можете объяснить, почему спешишь, чтобы они поняли, что вам нужно сделать.

Это как строить кирпичный дом. Когда у нас есть только один или два кирпича, уложенных на землю, мы можем легко сказать: «Му, я не люблю кирпич. Давайте использовать бамбук».

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

Будьте жестки относительно замораживания функций

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

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

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

Оливер Долан – дискретная часть функциональности, которую желают заинтересованные стороны

Если у вас есть веб-сайт с интерактивной картой, была бы новая функция создания «резервной» карты с другим поставщиком карт?

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

Потому мы можем втиснуть это в наш график как функцию.

4cUvVvqpUznMVlXLdn1PSBSHXxCH2GgeL-GO
Фото от rawpixel на Unsplash

Но как мы решим, стоит ли эта функция нашего времени?

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

  1. Что произойдет, если мы этого не введем?
  2. Каков в этом уровень приоритета?
  3. Есть ли у нас возможность взяться за эту работу, не откладывая дату запуска?

Будьте настойчивее в своих мыслях

Синдром самозванца оказывает влияние на нас на всех этапах нашей карьеры. Когда старший разработчик с 20-летним опытом говорит, давайте сделаем это таким образом, и вы не уверены на 100% в контраргументе, вы шепчете себе под нос: «О… хорошо».

Это то, что я делаю, когда не могу найти лучшее решение на месте.

Итак, как мы подготовимся к таким ситуациям?

  • Сначала поймите, как именно мы пришли к выводу
  • Сформулируйте свое решение посредством вопроса
  • Запишите, что вас беспокоит, и придумайте лучший способ сделать это позже
  • Совершенствуйте свои коммуникативные навыки

Если поначалу идея не абсурдна, то надежды на нее нет. – Альберт Эйнштейн

Сначала позаботьтесь о DevOps

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

Ждать двадцать минут, чтобы увидеть, как мои изменения появятся в сети, из-за вычурных конвейеров кода и проблем с подключением почти заставило меня ненавидеть кодировку. ?

Итак, как мы могли это сделать иначе?

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

Иметь контрольный список для тестирования

Чтобы предотвратить потерю времени при исправлении того же, вот несколько вещей, которые следует помнить при написании списка.

И я не говорю о написании кода для проверки вашего кода. Как часто мы что-то чиним, а что-то другое ломается?

2PICSsmZDVBuww5WTJrrBoJOq1CSw40fh6N6
«Человек, который составляет контрольный список в тетради», Гленн Карстенс-Питерс на Unsplash

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

  • Напишите контрольный список с точки зрения пользователя
  • Расширяйте список с помощью обратной связи по каждой итерации
  • Взгляните на список по-новому
  • Помогите другим разработчикам в команде проверить список

Упражняйте эмпатию

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

Например: если вы создали API, используемое веб-приложением, и собираетесь внести некоторые изменения в названия ключей данных.

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

LnfuxLIiDjt3m5qLBVUKQiFcshcSGAiWJoWY
Фото NESA от Makers на Unsplash

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

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

Спасибо, что прочли

Если вам понравилось это произведение, вы можете хлопать? чтобы больше людей могли воспользоваться этим.

Добавить комментарий

Ваш адрес email не будет опубликован.