×Закрыть

Сакрализация релиза

Одно из самых глупых явлений в современном мире разработки ПО — сакрализация релиза.

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

А ошибки все равно лезут и лезут.

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

Ни один «релиз менеджер», ни одно «многоуровневое тестирование» не защитит от проблем лучше, чем команда, которая:

1. Любит свой продукт.
2. Готова остаться допоздна и исправить любые проблемы.
3. Не релизит по пятницам.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нагнетание бессмысленной напряженности — это иди*тизм присущий непрофессионалам. Ошибки у отдельно взятых людей будут всегда, так как человеку свойственно ошибаться — это у него в природе. Другое дело, что можно построить процесс разработки так, что ошибок в релизе не будет вообще — примеров мало, но они есть. Если на это нет денег, времени, name it, то можно сделать три классических ветки: ветка dev — релиз после прохождения девелоперских тестов, ветка beta — релиз после переноса changeset’ов из dev-ветки и прохождения тестов QA, ветка release — новая версия при переносе запланированных фич из beta-ветки и прохождения тестов пользователей и отсутствия замечаний с их стороны. Релизить в каждую из веток можно хоть перед концом света и любимые пятницы тут не причем ;)

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

Тем не менее по пунктам 1-2-3 не очень соглашусь.
1. Зачем высокие слова? Можно просто ответственно и качественно делать свою работу.
2. А вот это лучше не надо. Если не релизить в конце рабочего дня (своего рода дополнение к 3), то у команды должно быть время для того, чтобы произвести починку путем roll-foward patch в нормальном режиме. Если же это не происходит — лучше откатываться, так как в этом случае команда очевидно недостаточно контролирует ситуацию и слишком велика вероятность каскадных регрессий в результате вечерних героических усилий.
3. В принципе логично. Хоть несколько противоречит 2: если вечером можно, то почему на выходных нельзя? :) При хорошо настроеном процессе continuous delivery может быть не так критично, врочем в таких сам еще не участвовал.

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

та эт вы не видили сколько мы обсуждали, кто будет писать строки в таблицу

Сакрализацию релиза не поддерживаю, считаю что всегда должна быть возможность оперативно исправить багу в релизнутой версии. Последний баг он предпоследний реально:)

Релизы в пятницу — это зло:)

хорошая, годная тема.

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

Что само собой значит свободные выходные, медали, успех и т. д.

Да и еще добавил бы пункт 4:

— НЕТ спешке.

да, релиз менеджера действительно и не нужно в маленьких командах ;)

а вот если вас уже 50+ и Внезапно приходится сидеть до позна.. оказывается тогда нужен

По заголовку я было подумал что топик о другом :-). Типа пицца, пати итд для девов в день релиза...

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

Любовь это конечно всегда хорошо, но есть еще технологии, процессы, инструменты — постепенно индустрия к этому приходит. Release early, release often уже вроде как мейнстрим, а не хулиганство. :-)

Не совсем согласен с пунктами 1-3:
1. В понятие «любить продукт» можно вкладывать очень разные вещи. Можна даже развить тему типа:
— Я люблю продукт.
— Нет я люблю больше.
— А я сильнее.
Правда не имеет смысла?
Ну в общем это не с той оперы. Я считаю, что есть такое понятие, как профессионализм. И конечно может не устраивать по каким то моментам место работы, проект, коллектив, технологии, домейн и многое еще чего. А может быть совсем наоборот. Но для професcионала такой подход — это не совсем серьезно. И такие проблемы решаются совсем по другому. В общем не в той плоскости.

2. Сразу вижу акцент на «остаться допоздна». А что по другому нельзя? Вот у меня в компании оффис закрывается в 20.00. На выходных вообще закрыт. Если есть желание — можешь по вечерам/на выходных работать по удаленке(часы ксатити посчитают и оплатят). Но такого понятия, как остаться до поздна — нет вообще в компании. Старожилы рассказывают, что за послендних 10 лет такая ситуация была 2-3 раза, на протяжении 2-3 дней в каждом случае. И то были ОЧЕНЬ критические моменты у живых клиентов (DHL, TNT, PostNL, Walmart и т.д.) после релиза.

3.Согласен. Идея правильная.

Но такого понятия, как остаться до поздна — нет вообще в компании. Старожилы рассказывают, что за послендних 10 лет такая ситуация была 2-3 раза, на протяжении 2-3 дней в каждом случае. И то были ОЧЕНЬ критические моменты у живых клиентов

Ну, что могу сказать — вам очень повезло или с компанией, или с клиентами, или с тем и другим вместе.

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

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

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

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

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

Когда это возможно, так и делают. Но если баг всплыл в критичном бизнес-сценарии, то это будет выглядеть как «вот вам автомобиль, можете в нем посидеть, послушать музыку, поднимать-опускать стекла, а вот ездить он будет только в следующем релизе»

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

есть такие случаи что находятся спецефические баги только после релиза и только на прод енве частного клиента.

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

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

А автор только идеальный код пишутс?
Будьте терпимие. Кто-то разгребает ваш говнокод, вы разгребаете чей-то.

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

просто во многих ваших сообщениях красной нитью скользит один мессадж — говнокод :)

Особенно когда даже стыдно признаться над какими программами работаешь:)

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

Мы собираем прошивку несколько раз в день. Когда пониманием что прошивка содержит требуемое количество новшеств и/или закрыты критические ошибки, то делаем релиз. Конечно, план какой-то есть, но +/- пару дней ничего не решают. Но все-равно, очень страшно когда меняются системные вещи (bsp, механизм защиты, механизм обновления), тут ошибка может стоить очень дорого.

Имхо наличие пункта 2 исключает пункт 3 :)

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

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

Це, шановний топікстартер, порівнювати налагоджені процеси і фанатичну команду — все одно, що порівнювати червоне і солодке...
Маємо такі варіанти:
1. ні процесів ні команди (очевидний фейл);
2. процеси є, команда не фанатіє;
3. процесів нема, команда фанатіє;

4. процеси є і команда фанатіє (оптимальний варіант);

Цілком очевидно, що варіант 2 ліпше ніж варіант 1, також очевидно варіант 3 ліпше ніж варіант 1.
Щодо співвідношення між 2 і 3 — можна сперечатися, мені думаєтся, що з фанатіючою командою таки піпше.

Але з усіх варіантів «4. процеси є, команда фанатіє» — найкращий. Головне тільки, щоб запроваження процесів було прозорим для команди, щоб від появи ритуалів та бюрократії не попропадав весь фанатизм, і варіант 4 не перетворився в варіант 2.

А буває взагалі, таке, що приходить хтось, якийсь «мега крутий менеджмент» (або «команда професійних консультантів»), і починає запроважувати «реформи процесів», такі, що і команда в унинії, і процеси всі виконуються тільки формально, аби щіталося, аби менеджмент відчепився...

Але це не процеси як явище виноваті, а дубові «реформатори», які обрали саме таку комбінацію процесів, або додумали туди якусь таку біду, що неможливо працювати...

Буває і навпаки. Процеси є, команада працює. Вчасно релізить, вчасно ходить додому. Приходить супер-пупер-фанатичний тех лід\PM і починає дерти одне місце... «Так поки не виправимо 10 критичних багів, ніхто додому не йде. А хто пішов в 21.00 — це зрадники, вони не люблять свій проект і не підтримують командний дух.» На щастя останній раз таке траплялося років 8 тому назад.
А для тих команд, де ще практикують такі підходи, пропоную відстоювати свої позиції, і не піддаватися на фанатичні закиди. Є робота, а є особисте життя. В особистому житті, часто є не менше релізів, багів, і інших пріоритетних та критичних задач.

Буває і навпаки.
Ага, буває.
А ще бувають градації поняття «фанатизм», отож «А хто пішов в 21.00 — це зрадники» явно перебор. А от не звітувати на проект години витраченні на перегляд розважальних сайтів, чи на «забивання козла» в комп’ютерних іграх, і натомість чесно присвятити положені 8год роботі (нехай і з перервами/розривами, але сумарний час корисної роботи, за яку, між іншим, бабки платять) — то є цілком здоровий фанатизм)

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

Можна добавить, что «команда фанатеет», и «команда профессионалов» — разные вещи, приводящие к разным результатам ;-)

it depends, мне нравится модель гитхаба, с релизами каждый день (и в пятницу тоже!), а то и несколько раз в день, но принимать это как рецепт для всех даже в вебе — точно нельзя.

Программист допустил ошибку в процессинге пеймента например — миллионы убытка у заказчика и его клиентов, поэтому я бы так не говорил.

Ну это просто еще одна история про «запуск шаттлов»: dou.ua/...ic/6398/#252645

Ну это просто еще одна история про «запуск шаттлов»
История проще:
Контора подписывает договор по которому работа должна быть сдана в срок Х. Если контора не сдает __полностью работающее приложение__ (баги не выше минора) ее нагибают. Шатлов нет, но контора жестко огребает.

Считается, что релиз — это очень опасно. Любая ошибка чревата катастрофой.

Для серьезных проектов релиз это действительно очень важно. И цена ошибки может быть высока. Потому что после релиза приложением начнут пользоваться сотни а может и тысячи юзеров.
Даже если это еще один интернет — магазин или финансовая программа то банальная ошибка в округлении может за день вылиться в четырехзначные убытки.
А сколько игрух выбрасывали «сырыми» и багливыми и в результате первые покупатели заваливали инет жалобами и проклятьями, перечеркивая все затраты на рекламу.
Про ошибки в медицинском ПО и говорить не приходится. Хорошо если их выявят на этапе сертификации и тогда просто запретят использование (то же убытки). А если пациент подаст в суд?
Никакая замечательная команда не сможет предотвратить эти проблемы. Потому что людям свойственно ошибаться. Тем более если они переживают за проект (нервы) и остаются допоздна (усталость).
Даже автоматизация тестирования не гарантирует 100% отсутствия ошибок. Ведь тесты пишут люди.

Поэтому и нужно «многоуровневое тестирование», а иногда еще и бета-тестирование множеством пользователей.

Веб-проектам (не критичным к ошибкам) просто — у них есть тысячи тестировщиков, способных обнаружить ошибки после релиза, которые остается только оперативно пофиксить :)

А что если хакеры обнаружат ошибку раньше?

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

Кажется, хакеры чаще обнаруживают ошибки в устаревших библиотеках, чем в собственно релизах. Интересно, например, как делает Google:
blog.chromium.org/...g-pwnium-2.html
korrespondent.net/...kij-programmist

Сейчас набегут те, кто считает мантру «09:00 — 18:00» священной коровой, которую ни-ни! И будут вас лечить, комментов эдак на 600 :)

Сейчас набегут те

Не «набегут», а «набежит».

Наверное лучше отдельно рассматривать варианты

аутсорсинг / продукт / свой продукт :)

Кстати, никогда не понимал вот эту линию конфликта «аутсорсинг — прдукт». То есть «любая наемная работа — свой продукт» — это понятно. А любой аутсорсинг в конце концов — это тоже продукт. Просто центральный офис в другой стране. Это должно менять отношение?

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

А любой аутсорсинг в конце концов — это тоже продукт.

Нет. Продуктовая контора зарабатывает на качественном продукте, аутсорс — на том чтобы человек для которого делают продукт был счастлив.

То есть эффективность работы аутсорсера далеко не всегда связана с качеством продукта.

Отношение меняет и очень сильно. Мотивация совсем другая.
Может быть аутсорсинговые компании бывают тоже разные. Но там где мне приходилось работать — разница огромная в отношениях «онсайт работник — продуктовая компания заказчим» и «аутсосинговый работник — аутсорсинговая комания — компания заказчик».
Наведу несколько примеров(подчеркну, что это не абсолютные истинны, а мой опыт) :
1. В работников продуктовой компании более четкие цели. Более понятная система вознаграждения. Намного сильнее ощущение, что именно ты привнес частицу к общему результату. Нет ощущения того, что компания постоянно пытается на тебе экономить. Если не на ЗП, то на рабочем месте, технике, офисе и т.д.
2. Работа в аутсорсинговой компании. Это в первую очередь работа на двух боссов. Надо удовлетворить и компанию заказчика, и компанию аутсорсера. Это особенно ощущается, когда начинаеш выполнять хотя бы частично менеджерские функции. Это постоянный баланс между двух боссов. Ощущения омерзительные — угодить и одному и другому. Как правило аусорсинговую компанию ОЧЕНЬ мало интересуют твои конкретные успехи на проэкте. Их главный интерес — маржа. С другой стороны твои успехи замечают на стороне заказчика, но поощрения, кроме как на словах, получиш очень редко. Это опят приводит к внутреннему конфликту. И отдавать сверхурочные силы — желание часто пропадает.
3. Есть еще модель аутстафинга. В этих случаях отношение с компанией посредником часто чисто формальные. Часто они даже не очень в курсе что там и как у заказчика. Заказчик же команду рассматривает в первую очередь, как сдешевление, а не как команду редких специалистов. Поэтому опять, как бы ты не работал, кроме слов благодарности ты ничего не получиш. Опять же, осознание того, что тебя в любой момент могут заменить, заасайнтить на другой проект, на другого кастомера, отдать, продать, перепродать — не мотивирует вообще. Я бы сказал даже совсем наоборот. Одно слово — наемник.

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

Та типа работая на продуктовую компанию получиш чтото больше.

Продуктовая компания знает за что ты работаеш. И если ты для ее проэкта выполняеш больше-лучше нежели от тебя ожидают, и если это важно (как правило важно), то это оценят. Или ЗП поднимут на пересмотре, или другую позицию предложат. Если ты действительно ценный работник, то расти можно и есть куда. С каждым годом ты прибавляеш свою стоимость как работник, имеющий опыт именно с этим продуктом.
Что же в аутсорсе — всегда стараются платить не больше чем можно менше. Успехи на проекте — ну молодец, работай дальше. Хочешь ЗП больше, хочешь расти, у тебя опыт в рамках этого заказчика. А нам какая разница, у нас договор с заказчиком на тебя по таким рейтам. Мы занижать свои доходы не будем. Проще перевести тебя на другой проэкт. И т.д.
Другими словами в продуктовой компании атмосфера — это работа над програмным продуктом. Конечно продукт должен приносить прибыль. Чем лучше мы будем работать, тем успешнее продукт. А что значит лучше? А лучше это инновации, лучшие технические решения, лычшие технологии в контексте продукта и т.д. То есть четко видна технологическая составляющая, в которой заинтересована компания.
А что у нас в аутсорсинге, какие бизнес цели? Повыше взять внешние рейты у заказчика, пониже заплатить программистам. Побольше нанять людей. Побольше часов отрепортить. В конце месяца посчитали маржу — ух молодцы, бизнес работает. Так, какие меропреятия нужно провести в жизнь еще, чтобы увеличить маржу? Видите тут технологическую составляюющую в бизнес моделе? Я нет. И чем плох Украинский аутсорс (другого я не знаю), если б хотя открыто не светили, хотя бы на бытовом уровне, свои бизнес цели человеко-часов * маржа — и то бы было намного комфортнее работать. С моего же опыта эта модель бизнеса человеко-часов * маржа проходит красной нитью каждый час отработанный на аутсорс. Какая тут может быть мотивация в дальнесрочной перспективе?

P.S.
Я не собираюсь спорить в глобальном теоретическом масштабе на эту тему. Вполне допускаю что аутсорсы бывают (теоретически) лучше, чем в моем случае, и продуктовые компании хуже, чем в моем случае. Это всего лишь мой частный опыт.

Про атмосферность и бизнес ориентированность, я конечно согласен.
Но вот с

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

опыт показывает прямопротивоположное. Потому мне не нравятся местные возведения в абсолют продуктовых компаний.

Та ну. Модель зависит не от этого.

«09:00 — 18:00» священной коровой, которую ни-ни!

Почему же ни — ни, оплачиваем переработку в двойном размере и пожалуйста.

Чего это я должен засиживаться до поздна за бесплатно?

Вот тут, наверное, противоположная ситуация:

kholeg.wordpress.com/...равильную-вещь

Да, противоположная. И я немного гиперболизирую, как и в теме про С(к)рам. Но ведь далеко не все проекты — это «запуск шаттлов». Это не значит, что в маленьких командах должен быть хаос. Но излишняя увлеченность процедурами все только портит, переводя акценты на второстепенное. С хорошими программистами можно и «отредактировать вот этот файл на продакшне», а с плохими ничто не поможет.

2. Готова остаться допоздна и исправить любые проблемы.

Сейчас сами_знаете_кто придет из спорт-зала и расскажет вам что вы не правы :)

Ни один «релиз менеджер», ни одно «многоуровневое тестирование» не защитит от проблем лучше, чем команда, которая:

Задача «релиз менеджера» сделать так чтобы не надо было сидеть по ночам фикся баги.

Любая ошибка чревата катастрофой.

У кого-то чревата, у кого-то нет.

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

Ок, вместо «остатья допоздна» может быть «прийти пораньше» или просто «ударно поработать в течение дня». Смысл в том, что гораздо важнее способность оперативно исправить ошибку, чем святая вера в то, что ее можно гарантировано предотвратить. On a side note, овертаймы — естественная составляющая работы в IT. Это не значит, что они должны быть постоянными, но полностью избавиться от них невозможно. Слышал историю, что VC в Калифорнии оценивают проект по горящим окнам в офисе субботним вечером. Кому принципиально не подходят овертаймы лучше подойдет другая работа.

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

Ассенизатор — звучит гордо.©

Слышал историю, что VC в Калифорнии оценивают проект по горящим окнам в офисе субботним вечером.

Сергей, в США не принято в офисах выключать электричество. Ни на ночь, ни на выходные.

Может, это такая себе urban legend. Или там речь шла о машинах на парковке.

овертаймы — естественная составляющая работы в IT. Это не значит, что они должны быть постоянными, но полностью избавиться от них невозможно.

А вот и нифига, можно избавиться — платить за овертайм в двойном размере.

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

VC в Калифорнии оценивают проект по горящим окнам в офисе субботним вечером.

Да ты знаешь, как то мне на Калифорнию плевать.

Кому принципиально не подходят овертаймы лучше подойдет другая работа.

Возможно, тут вопрос в том какая работа :)

On a side note, овертаймы — естественная составляющая работы в IT.

Овертаймы — естественная составляющая работы на себя, неважно, в айти или в ремонте сантехники.

Кому принципиально не подходят овертаймы

Я неоднократно исправлял свои собственные ляпы до «победы» без каких-то требований оплаты. Но гораздо чаще речь идёт о сверхурочных ради прикрытия чьей-то управляющей жoпы, улучшения каких-то там показателей, сроков. Тут ушш извините.

Слышал историю, что VC в Калифорнии оценивают проект по горящим окнам в офисе субботним вечером.

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

Ну понеслась.
TODO: Купить попкорн по дороге с работы.

18:29, а вы еще не дома??? :)

Я тут с вами не соглашусь. Ибо на кануне релиза «оно» само снизосходит на вас без всяких менеджеров или кого либо. Ибо банально хочется чтобы за свою работу было перед пользователями не стыдно...

Покритикую.

1. Любить свой продукт тяжеловато. Это надо быть или супер-спецом или реально делать что — то интересное, любить унылое г..., весьма сложно. Соответственно да, этот пункт поможет, но реализация его весьма сложна.

2. Да, конечно, готова остаться, а также готова умереть вл славу релиза! оставаться допохдна — это плохо, очень плохо. Соответственно надо не оставаться допоздна, а планировать и внедрять бест практисез.

3. Согласен, но обычно так удобнее.

1. Согласен. Очень сложно. К тому же со временем команда меняется.
2. Это как раз несложно. Если конечно овертайм не каждый день.

3. Релиз тогда, когда это нужно заказчику. Все онлайновое вообще часто релизят в ночь с субботы на воскресенье.

1. Любить свой продукт тяжеловато. Это надо быть или супер-спецом или реально делать что — то интересное, любить унылое г..., весьма сложно. Соответственно да, этот пункт поможет, но реализация его весьма сложна.

С моей позиции какраз наоборот. Тяжело не «любить» чтото что зделанно тобою, что реально пользователи используют. Для меня самое нелюбимое дело, это какраз если оно нафиг никому не надо. Тут внатуре — чего время терять, уж лутше пива попить, итд.

Подписаться на комментарии