Как да направите своя стартиращ процес разходка в парка

Снимка на Джейми Тейлър на Unsplash

Беше 2 часа сутринта. Телефонът ми все още бръмчеше от разговори на програмисти за това как да боравите с 404 страници. Това беше само началото ...

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

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

Както законът на Мърфи гласи:

Всичко, което може да се обърка, ще се обърка.

Как да стартираме продукт и да гарантираме, че нещо НЕ се обърка (доколкото можем)?

По-долу е бета версията на моята стратегия за следващото стартиране.

Имайте съдържание за първата седмица

Когато кажете на клиента, че датата на стартиране е на месец, списъкът с данни и активи, необходими за стартиране, се погребват във входящата му поща и изскачат само седмица преди старта.

В крайна сметка ние търсим неща заради резките промени в изображенията и текста - „малките неща“.

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

По време на тази комуникация напред-назад се губи ценно време.

„Група хора мозъчна атака над лаптоп и листове хартия“ от Štefan Štefančík в Unsplash

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

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

Какво става, ако клиентът каже: „Размразяване… брато, ние сме на това.“ И няма ясно действие, което виждате, че сте предприети?

Бихте могли да обясните защо бързате, така че те получават контекста зад всичко, което трябва да направите.

Това е като изграждане на тухлена къща. Когато имаме само една или две тухли на земята, лесно можем да кажем: „Мех, не харесвам тухла. Нека използваме бамбук. "

Но ще е необходимо чудо да замените тухлите с бамбук, когато тухлената къща е близо до завършване. В най-добрия случай ще изградим неясна къща (продукт), ако това е така, или датата на стартирането ни ще бъде забавена.

Бъдете твърди по отношение на функцията за замразяване

Замразяването на функции е удобна концепция, която се казва по-лесно, отколкото се направи.

В софтуерното инженерство замразяването е момент от процеса на разработка, след който правилата за извършване на промени в изходния код или свързаните с него ресурси стават по-строги или периодът, през който тези правила се прилагат - Wikipedia

В допълнение към задаването на функцията за замразяване седмица преди датата на стартиране, ние също трябва да сме наясно каква е функцията.

Дискретна част от функционалността, желана от заинтересованите страни - Оливър Долан

Ако имате уебсайт с интерактивна карта в него, ще бъде ли нова функция да изградите „резервна“ карта с друг доставчик на карти?

Нашият мисловен процес може би е бил, че тъй като сме в Китай, няма гаранция, че първият ни избор на доставчик на карта няма да бъде блокиран.

Така че можем да го впишем в графика си като функция.

Снимка от rawpixel в Unsplash

Но как да решим дали тази функция си заслужава нашето време?

Ето въпросите, които да зададете на вашия екип и клиент за всяка функция, която планирате да внедрите

  1. Какво се случва, ако не приложим това?
  2. Какво е приоритетното ниво на това?
  3. Имаме ли капацитет да поемем тази работа, без да забавяме датата на стартиране?

Бъдете по-настоятелни със своите мнения

Синдромът на Imposter ни засяга на всички етапи от кариерата ни. Когато старши разработчик с 20-годишен опит казва, нека го направим по този начин, а вие не сте 100% сигурни в контра аргумент, шепнете под дъха си: „О… добре“.

Това правя, когато не мога да намеря по-добро решение на място.

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

  • Разберете как точно стигнахме до заключението
  • Формулирайте решението си като въпрос
  • Напишете какво ви притеснява и помислете за по-добър начин да го направите по-късно
  • Подобрете своите комуникационни умения
Ако в началото идеята не е абсурдна, значи няма надежда за нея. - Алберт Айнщайн

Първо се погрижете за DevOps

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

Изчакване на двайсетина минути, за да видя промените ми да дойдат онлайн поради фантазии с тръбопроводи с кодове и проблеми с връзката почти ме накараха да мразя кодирането.

И така, как бихме могли да го направим по различен начин?

  • Средата Dev трябва да може да се променя бързо.
  • Ако автоматизацията не пести време, това не е автоматизация.
  • Използвайте доставчик на облак, който отговаря на вашите нужди
  • Уверете се, че процесът на внедряване е плавен от първата седмица

Имайте контролен списък за тестване

За да предотвратите загубеното време, докато коригирате едно и също нещо, ето няколко неща, които трябва да имате предвид, когато пишете списъка.

И не говоря за писане на код, за да тествам кода. Колко често поправяме нещо и нещо друго се счупва?

„Лице, което прави контролен списък в тефтер“ от Glenn Carstens-Peters на Unsplash

За да не се налага да коригирате едно и също нещо отново и отново, ето няколко неща, които трябва да имате предвид, когато пишете списъка.

  • Напишете контролния списък от гледна точка на потребителя
  • Разширете списъка с отзивите от всяка итерация
  • Проведете свеж набор от очи през списъка
  • Помогнете на други разработчици в екипа да проверят списъка

Практикувайте съпричастност

Без значение в каква позиция сте. Малката емпатия стига дълъг път.

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

Разбирате, че конкретните имена на ключове за данни може да са били включени навсякъде от друг разработчик в уеб приложение. Уведомете активно други разработчици, преди нещата да започнат да се объркат.

Снимка на NESA от Makers на Unsplash

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

Всяка роля в екип е изправена пред собствени препятствия. Способността да се поставите в различни обувки ще ви промени от само разработчик, който записва код в лидер, който изпраща висококачествен стабилен код.

Благодаря за четенето

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