Мой личный опыт (разработчик и внезапный генеральный директор продуктовой микро компании) показывает, что фич, которые приносят деньги и не оттестированы не бывает в природе. В основном они приносят внезапный головняк, что для микро компании чревато срывом сроков по другим продуктам. Поэтому обычно переговоры с разработчиками ведутся по вопросу, как написать фичу без оверинжиниринга, а не о том надо ли ее писать без тестов и под рефакторинг или не надо.
Если продакт менеджер говорит а почему 20, давай 10 и его нужно убеждать в том, что писать новую фичу без тестов и сразу под рефакторинг это плохо, то это говорит о его потенциальной профнепригодности. Адекватный диалог - должен звучать так:
20 часов?
Качественно и с тестами?
Да
Ок, вперед. (Или если во время не укладываемся) Ладно выпустим в следующем релизе.
Бюрократии, возможно, больше, чем в РФ (но я не был в РФ в качестве иностранца, так что не знаю), но она на 99% сидя в кресле дома попивая кофеёк лениво разбираться с онлайн-формами (иногда помощью Google Translate, но опять же я сам виноват в этом), а не часами от руки заполнять бесконечные бланки на подоконнике какого-нибудь госучреждения с очередью недовольных за спиной. ЭТО ДРУГОЕ.
Я ту недавно, в Москве, менял генерального директора в ООО, после внезапной гибели предыдущего гендиректора, который в то-же время являлся владельцем 50% доли этого ООО. Это достаточно неприятный казус в таком сочетании. И ни разу не сидел на подоконниках и не заполнял бланки. В основном процесс построен так, что тебе присылают инструкции, которые ты выполняешь. И даже в этом тяжелом случае, обычный программист, которым я по сути являюсь, справился с возвратом управления компании. Так что как минимум в Москве с бюрократией все замечательно.
Это миф о мифах, за 15 лет работы в постсоветском IT такие подходы к работе я не встречал ни разу. Зато постсоветское IT характеризуется подходом - сначала попытаться разобраться, почитать документацию, погуглить, а потом уже писать вопросы в поддержку. И это отличный, экономящий огромное количество времени подход к работе.
Мой личный опыт (разработчик и внезапный генеральный директор продуктовой микро компании) показывает, что фич, которые приносят деньги и не оттестированы не бывает в природе. В основном они приносят внезапный головняк, что для микро компании чревато срывом сроков по другим продуктам. Поэтому обычно переговоры с разработчиками ведутся по вопросу, как написать фичу без оверинжиниринга, а не о том надо ли ее писать без тестов и под рефакторинг или не надо.
Если продакт менеджер говорит а почему 20, давай 10 и его нужно убеждать в том, что писать новую фичу без тестов и сразу под рефакторинг это плохо, то это говорит о его потенциальной профнепригодности. Адекватный диалог - должен звучать так:
20 часов?
Качественно и с тестами?
Да
Ок, вперед. (Или если во время не укладываемся) Ладно выпустим в следующем релизе.
...кровати двигает
Я ту недавно, в Москве, менял генерального директора в ООО, после внезапной гибели предыдущего гендиректора, который в то-же время являлся владельцем 50% доли этого ООО. Это достаточно неприятный казус в таком сочетании. И ни разу не сидел на подоконниках и не заполнял бланки. В основном процесс построен так, что тебе присылают инструкции, которые ты выполняешь. И даже в этом тяжелом случае, обычный программист, которым я по сути являюсь, справился с возвратом управления компании. Так что как минимум в Москве с бюрократией все замечательно.
Это миф о мифах, за 15 лет работы в постсоветском IT такие подходы к работе я не встречал ни разу. Зато постсоветское IT характеризуется подходом - сначала попытаться разобраться, почитать документацию, погуглить, а потом уже писать вопросы в поддержку. И это отличный, экономящий огромное количество времени подход к работе.