Давненько не писал в блог. Очень много работы в последнее время, зачастую нет времени банально пойти поесть или даже ... нет не будем об этом.
Перебирая почту нашел рассылку от InfoQ в которой была ссылка на книгу "Patterns of Agile Practice of Adoption The Technical Cluster". Решил поделиться мыслями о прочитанном.
Business Value.
В процессе жизненного цикла Delivery какой то функциональности, я уделяю много внимания деталям, я не хочу сказать что это плохо, наоборот, продумывая все возможные варианты и углубляясь в детали я делаю свой продукт лучше. Но, лучше для кого? для себя? потому что я разобрались с очередной нетривиальной задачей и потешили свое самолюбие, или для конечного пользователя?
Для меня, поле моего интереса заканчивается примерно тогда, когда я написал код, который по моему хорошо работает и решает описанную задачу. Есть мнение что для аналитика он заканчивается тогда, когда он провел анализ и разложил все по полочкам, так, чтобы это понятно было мне, как разработчику, а для специалиста по качеству, когда функциональность протестирована и все может идти в релиз. Я конечно сейчас говорю о людях которые получают кайф от своей работы, а не приходят туда для того чтобы отметится, потому что иначе не переведут на карточку ЗП, и вообще попросят написать заявление по собственному желанию. Потому что с такими нужно прощаться сразу так чтобы они не тянули команду вниз во всех смыслах этого слова.
Человек существо эгоистичное, но если поднять немного выше голову то можно найти еще источник удовлетворения своего самолюбия. И этим источником является конечный пользователь, кастомер, не знаю как вы его называете. Но, надеюсь мы все понимаем одно и тоже под этими словами.
Кастомер существо благодарное, и если говорить о материальной стороне, то если вы делаете качественный продукт, то с вами перезаключат контракт, если ваш продукт сэкономил кучу денег кастомеру то наверняка он с вами поделится и т.д. или вообще отбросим материальную сторону и представим, что вашей фичей стали пользоваться кучу народу и благодарны вам за её.
Мораль.
Доводите свой продукт общими усилиями, а не кидайте дело, когда оно выходит за пределы вашей специализации.
Собирайте отзывы от конечных пользователей, в конце концов, если не учитывать бабло которое вам платят, это самое главное, ибо в отзыве отражается качество анализа, технического решения и тестирования
Вырабатываете практики, которые вам позволят избавиться от рутинной работы во время Delivery.
Не бойтесь экспериментировать, пробуйте разные подходы и практики, выступайте в разных ролях в команде, это позволит лучше понять все стороны и этапы разработки анализа и тестирования.
Эволюционируете всей командой а не по частям, делитесь опытом.
Заражайте остальные команды которые вокруг вас своей производительностью.
В противном случае ~40 процентов жизни, которую вы проводите на работе превращается в угрюмое и унылое времяпрепровождение.
Перебирая почту нашел рассылку от InfoQ в которой была ссылка на книгу "Patterns of Agile Practice of Adoption The Technical Cluster". Решил поделиться мыслями о прочитанном.
Business Value.
В процессе жизненного цикла Delivery какой то функциональности, я уделяю много внимания деталям, я не хочу сказать что это плохо, наоборот, продумывая все возможные варианты и углубляясь в детали я делаю свой продукт лучше. Но, лучше для кого? для себя? потому что я разобрались с очередной нетривиальной задачей и потешили свое самолюбие, или для конечного пользователя?
Для меня, поле моего интереса заканчивается примерно тогда, когда я написал код, который по моему хорошо работает и решает описанную задачу. Есть мнение что для аналитика он заканчивается тогда, когда он провел анализ и разложил все по полочкам, так, чтобы это понятно было мне, как разработчику, а для специалиста по качеству, когда функциональность протестирована и все может идти в релиз. Я конечно сейчас говорю о людях которые получают кайф от своей работы, а не приходят туда для того чтобы отметится, потому что иначе не переведут на карточку ЗП, и вообще попросят написать заявление по собственному желанию. Потому что с такими нужно прощаться сразу так чтобы они не тянули команду вниз во всех смыслах этого слова.
Человек существо эгоистичное, но если поднять немного выше голову то можно найти еще источник удовлетворения своего самолюбия. И этим источником является конечный пользователь, кастомер, не знаю как вы его называете. Но, надеюсь мы все понимаем одно и тоже под этими словами.
Кастомер существо благодарное, и если говорить о материальной стороне, то если вы делаете качественный продукт, то с вами перезаключат контракт, если ваш продукт сэкономил кучу денег кастомеру то наверняка он с вами поделится и т.д. или вообще отбросим материальную сторону и представим, что вашей фичей стали пользоваться кучу народу и благодарны вам за её.
Мораль.
Доводите свой продукт общими усилиями, а не кидайте дело, когда оно выходит за пределы вашей специализации.
Собирайте отзывы от конечных пользователей, в конце концов, если не учитывать бабло которое вам платят, это самое главное, ибо в отзыве отражается качество анализа, технического решения и тестирования
Вырабатываете практики, которые вам позволят избавиться от рутинной работы во время Delivery.
Не бойтесь экспериментировать, пробуйте разные подходы и практики, выступайте в разных ролях в команде, это позволит лучше понять все стороны и этапы разработки анализа и тестирования.
Эволюционируете всей командой а не по частям, делитесь опытом.
Заражайте остальные команды которые вокруг вас своей производительностью.
В противном случае ~40 процентов жизни, которую вы проводите на работе превращается в угрюмое и унылое времяпрепровождение.
No comments:
Post a Comment