А программист не намекает менеджеру, что в месяце фиксированное количество дней и что само переключение между задачами небесплатно? Есть ли что-то типа кабан доски с фиксированным work-in-progress? Как отслеживается трудоемкость задач? Что менеджер думает о статье Спольски «О вреде премирования?
Вы вначале написали «Править чужой код всегда стресс» я так понял что всегда, получается, и заставляют. Но если акцент на этом слове, то можно согласиться
Статья по тону такая же негативистская как и паттерны, которые она критикует. Запанибратская стилизация и позиция сверху создают впечатление, что истинная цель — повышение самооценки за чужой счет.
Если хотя бы одному разработчику статья окажется полезной — писал не зря.
Не слишком ли скромный критерий успеха для человека который управляет разработчиками — а они и есть аудитория статьи?
1. Если у вас на компе работает, вполне возможно, что есть какой-то параметр, который пользователь не указал в багрепорте и его надо уточнить. Это если цель сделать качественное ПО, а не отказаться
2. Если у вас в разработке роль безмолвного исполнителя ТЗ бага, вероятно, прошла через приоретизацию при помощи того де человека, что и составлял т.з. соответственно, он уже учёл требования к пользователю — т.е. посчитал его неопытных а не мудаком.
3. Иногда полезно подумать, почему вообще бага возникла и как так больше не делать. Как такие баги находить быстрее? Не стоит ли тестерам сообщить — какие места лучше протестировать поподробнее и какие автоматические тесты лучше написать? Наше дело не искать виноватых, а вместе делать качественное ПО.
4. Согласен, правда я бы не тыкал, а задавал наводящих вопросы сначала — иногда есть какие-то обстоятельства, которых не знаешь.
5. На на доступном менеджеру языке обозначить причину задержки. Постараться разбить задачу на маленькие порции, чтобы говорить либо о 100% сделанной порции либо о несделанной. Поискать другие варианты или попросить коллегу покопаться вместе. В следующий раз перед оценкой отделить те куски, в которых ты не уверен и сообщить менеджеру. Сначала написать короткий прототип, в котором изучить сомнительные места jQuery. «Будет готово через 3 часа, если все пойдет гладко, но чтобы сказать точно надо сначала попробовать вот это — через полчаса скажу точнее».
6. Может быть ленивый разработчик, тупой менеджер или сочетание :).
7. Если предполагаемая «ерунда» не входит в обязанности разработчика, адекватный человек сообщит это другими словами не провоцируя конфликт.
Есть очень много разных штатных ситуаций, почитайте например про collective code ownership. Да и в опенсурсе сплошь и рядом. Конечно, это требует навыка.
Разве дело программистов приоритезация задач? Программист называет свою оценку, а PM уж решает выполнять или нет и в каком порядке. Если задачи оценены, то «впихивание до кучи» приводит только к разрастанию кучи во времени и отодвигает релиз/сдачу этапа. Если менеджемент этого не понимает, надо его учить или увольняться.
Заметьте, что вы пришли к общему знаменателю только после серии уточняющхе комментов. Могло быть «у меня не воспроизводится и они не могут повторить еще раз» или «у меня не воспроизводится, я послал письмо с уточняющими вопросами и они пока не отвечают». Мне кажется, или в каждом пункте нужно пояснение с разбором РАЗНЫХ ситуаций или этот список тривиален. То есть у тех, кто не понимает о чем идет речь такое вызовет только раздражение а остальным просто ничего не даст
Судя по отсутствию пункта 000 автор сам не до конца знает то, подо что стилизует список :)
За остальными пунктами может скрываться примерно по миллиону разных ситуаций.
Например, «это сделать невозможно» может обозначать лень, противоречие в ТЗ, слишком большую трудоемкость и т.п.
Если у нас есть хороший менеджер и средний разработчик, то первый наверняка выяснить у второго почему невозможно и какие есть варианты удовлетворить потребности клиента. Если у нас хороший (с точки зрения навыков коммуникации) разработчик, то он может скомпенсировать посредственность менеджера тем, что сам попытается выяснить, что надо в итоге и предложит удовлетворить потребности конечного пользователя другим способом.
Думаю, еще в этом ответе — «это сделать невозможно» — раздражает упрямая категоричность.
Айтишники не все вебом занимаются. Всякие одинесконфигурасты и сисадмины бывает такое говорят. Но часть, наверное ломает говорить джааваааскриипт и они говорят «ява» просто для краткости ( так как js щас везде, а Джава только у избранных ;-)
Я думаю, на хабре все-таки аудитория с особыми потребностями. Например, для моей жены не нужно шифрование всего на дропбоксе, а отзывчивый интерфейс на слабом оборудовании и отсутствие «обновлений оперы» нужно
при этом они почему-то все-равно стоят почти как бумажные. при, по сути, меньших правах, потому что
Важная новость: цена устанавливается не согласно законам справедливости, а в результате уравновешивания спроса и предложения. Они так стоят, потому, что их покупают. Я, например, покупаю довольно много электронных книжек, чтобы не мучаться с доставкой, а «дать почитать» мне нужно редко.
я не заключаю никакого договора с издателем, так как не покупаю у него книгу.
Я больше не про вас, а про автора, который принимает от вас деньги за факт пиратства.
Вы же можете не пользоваться книгой и не платить, пользоваться книгой и платить, но вы выбираете третий вариант: пользоваться и не платить. Таким образом, вы используете продукт произведенной в рамках бизнес модели копирайта нахалявочку не давая этой системе ничего взамен. (Причем у вас есть возможность выбрать вместо этого что-нибудь бесплатное)
Не знаю, нет ли в этом нарушения какого-то общественного договора.
Еще интересная мысль: рядышком уже есть некоторый объем контента, который можно потреблять бесплатно, но он почему-то не спешит вытеснять платный контент подобно тому как бесплатные браузеры вытеснили платные. Как вы думаете почему?
«Это было бы верно в случае, если бы экземпляр книги был один.»
Опять путаница с терминами. Давайте разделим книгу как произведение и книгу как конкретный экземпляр. Вам дают попользоваться кусочек произведения в виде конкретного экземпляра. Права собственности на произведение у вас не возникает.
«А так — стоимость раскидывается на тираж (зачастую — не один).»
Как и в случае с арендой велосипеда.
«Мы же говорим о правах. Причем если бумажную книгу я могу отдать в библиотеку, то электронная — только для личного пользования.»
Если вы попытаетесь ее использовать для создания копий — то это будет незаконно.
Электронную вы не можете отдать в библиотеку, потому, что это бессмысленно (электронные библиотеки получают их у издателей).
«Как ни прискорбно, но я продолжаю качать книги с торрентов и при случае пересылать деньги напрямую авторам»
Нашли чем удивить. Для русских справедливость выше договора (разумеется их понимание справедливости). Автор почему-то решил передать права на произведение издателю, хотя мог бы честно и сам его продавать собирая по копеечке — без жирных посредников. Но он почему-то выбирает распространение через посредника.
Словом «книга» обозначается обычно две разные вещи — материальный носитель с записанной информацией на нем и сама информация. Стоимость книги в первом случае — это стоимость носителя + аренда информации. Во втором случае — это полные права на использование информации. Себестоимость и стоимость последнего существенно больше чем вы платите за экземпляр книги.
Покупая книгу вы покупаете носитель + ограниченное право использовать информацию на книге.
Просто, в случае с бумажной книгой, часть ограничений традиционно связана с физическими ограничениями носителя. Я думаю, как только вы найдете способ предоставить бумажную книгу достаточно большом количеству людей одновременно, его тоже будут ограничивать.
Если вам не нравятся читать электронные книги на таких условиях не вступайте в такие сделки. Большинство, почему-то, вступает.
Если хотя бы одному разработчику статья окажется полезной — писал не зря.
Не слишком ли скромный критерий успеха для человека который управляет разработчиками — а они и есть аудитория статьи?
2. Если у вас в разработке роль безмолвного исполнителя ТЗ бага, вероятно, прошла через приоретизацию при помощи того де человека, что и составлял т.з. соответственно, он уже учёл требования к пользователю — т.е. посчитал его неопытных а не мудаком.
3. Иногда полезно подумать, почему вообще бага возникла и как так больше не делать. Как такие баги находить быстрее? Не стоит ли тестерам сообщить — какие места лучше протестировать поподробнее и какие автоматические тесты лучше написать? Наше дело не искать виноватых, а вместе делать качественное ПО.
4. Согласен, правда я бы не тыкал, а задавал наводящих вопросы сначала — иногда есть какие-то обстоятельства, которых не знаешь.
5. На на доступном менеджеру языке обозначить причину задержки. Постараться разбить задачу на маленькие порции, чтобы говорить либо о 100% сделанной порции либо о несделанной. Поискать другие варианты или попросить коллегу покопаться вместе. В следующий раз перед оценкой отделить те куски, в которых ты не уверен и сообщить менеджеру. Сначала написать короткий прототип, в котором изучить сомнительные места jQuery. «Будет готово через 3 часа, если все пойдет гладко, но чтобы сказать точно надо сначала попробовать вот это — через полчаса скажу точнее».
6. Может быть ленивый разработчик, тупой менеджер или сочетание :).
7. Если предполагаемая «ерунда» не входит в обязанности разработчика, адекватный человек сообщит это другими словами не провоцируя конфликт.
За остальными пунктами может скрываться примерно по миллиону разных ситуаций.
Например, «это сделать невозможно» может обозначать лень, противоречие в ТЗ, слишком большую трудоемкость и т.п.
Если у нас есть хороший менеджер и средний разработчик, то первый наверняка выяснить у второго почему невозможно и какие есть варианты удовлетворить потребности клиента. Если у нас хороший (с точки зрения навыков коммуникации) разработчик, то он может скомпенсировать посредственность менеджера тем, что сам попытается выяснить, что надо в итоге и предложит удовлетворить потребности конечного пользователя другим способом.
Думаю, еще в этом ответе — «это сделать невозможно» — раздражает упрямая категоричность.
Как и в тоне автора поста.
Будь гибче, чувак!
Важная новость: цена устанавливается не согласно законам справедливости, а в результате уравновешивания спроса и предложения. Они так стоят, потому, что их покупают. Я, например, покупаю довольно много электронных книжек, чтобы не мучаться с доставкой, а «дать почитать» мне нужно редко.
я не заключаю никакого договора с издателем, так как не покупаю у него книгу.
Я больше не про вас, а про автора, который принимает от вас деньги за факт пиратства.
Вы же можете не пользоваться книгой и не платить, пользоваться книгой и платить, но вы выбираете третий вариант: пользоваться и не платить. Таким образом, вы используете продукт произведенной в рамках бизнес модели копирайта нахалявочку не давая этой системе ничего взамен. (Причем у вас есть возможность выбрать вместо этого что-нибудь бесплатное)
Не знаю, нет ли в этом нарушения какого-то общественного договора.
Еще интересная мысль: рядышком уже есть некоторый объем контента, который можно потреблять бесплатно, но он почему-то не спешит вытеснять платный контент подобно тому как бесплатные браузеры вытеснили платные. Как вы думаете почему?
Опять путаница с терминами. Давайте разделим книгу как произведение и книгу как конкретный экземпляр. Вам дают попользоваться кусочек произведения в виде конкретного экземпляра. Права собственности на произведение у вас не возникает.
«А так — стоимость раскидывается на тираж (зачастую — не один).»
Как и в случае с арендой велосипеда.
«Мы же говорим о правах. Причем если бумажную книгу я могу отдать в библиотеку, то электронная — только для личного пользования.»
Если вы попытаетесь ее использовать для создания копий — то это будет незаконно.
Электронную вы не можете отдать в библиотеку, потому, что это бессмысленно (электронные библиотеки получают их у издателей).
«Как ни прискорбно, но я продолжаю качать книги с торрентов и при случае пересылать деньги напрямую авторам»
Нашли чем удивить. Для русских справедливость выше договора (разумеется их понимание справедливости). Автор почему-то решил передать права на произведение издателю, хотя мог бы честно и сам его продавать собирая по копеечке — без жирных посредников. Но он почему-то выбирает распространение через посредника.
Покупая книгу вы покупаете носитель + ограниченное право использовать информацию на книге.
Просто, в случае с бумажной книгой, часть ограничений традиционно связана с физическими ограничениями носителя. Я думаю, как только вы найдете способ предоставить бумажную книгу достаточно большом количеству людей одновременно, его тоже будут ограничивать.
Если вам не нравятся читать электронные книги на таких условиях не вступайте в такие сделки. Большинство, почему-то, вступает.
продается не информация, а ограниченное право ее использования.
типа «я взял в прокат велосипед и хочу им распоряжаться как своим»