0. Пять итераций для того, чтобы подвинуть надпись на пару пикселей (предварительно сделав нехитрые вычисления с учетом DPI) — действительно перебор.
Пункты 1 и 2 и 3 требований я бы завернул. Объяснил бы заказчику, что есть общепринятый стандарт, и если поведение программы в корне отличается от поведения операционной системы, это, мягко скажем, запутывает. Если не поймет — сформулировал бы так, что на второй раз до него бы точно дошло.
4. Сфоткать штаны, сделать цветопробу и соответствующим образом поменять фон. Клиент офигеет от внимательности, потом передумает (цвет соответствует, но не нравится), а мы выкатываем дополнительную трудоемкость и просим оплатить. В следующий раз клиент говорит себе: «да, ребята внимательные, делают то, что я прошу. Я в следующий раз буду думать прежде, чем просить — а вдруг самому не понравится?»
5. Накурите клиента, анимация будет работать и на бумаге.
6. Да, это повод не делать фичу, телепаты в отпуске.
7. Для таких экземпляров нужно чаще ставить босса в CC, вдруг переведутся.
Чтобы не допустить такой ситуации, достаточно было задать вопрос: «перенос нужен однократный или потребуется возможность повторного»? Чтобы задавать такие и подобные вопросы, согласитесь, нужен опыт и некоторая дотошность.
Формально: подписание технического акта означает согласие принимающей стороны с корректностью реализации. Трактовка требований неоднозначна. Здесь я полностью на стороне разработчика, но приложил бы максимум разумных усилий для того, чтобы сохранить лояльность заказчика.
Когда в начале своего становления как программиста я столкнулся с п.1, решил не заморачиваться и просто сменил проект. Нервы дороже.
Спихивание вины — это проблема людей. Стараюсь не связываться со «стрелочниками». К сожалению, не всегда получается.
Сейчас могу уверенно ответить с позиции этого самого супер-мэна. Здесь я вижу два объяснения:
1. возможно, он действительно эгоцентрист, либо страдает неуверенностью в себе и не хочет, чтобы кто-то набирался знаний и стал лучше него.
2. компания, зная его талант, старается выпользовать его на полную, закидывая задачами, и у него объективно (!) не хватает времени на то, чтобы оторваться от кода и понятно развернуто ответить. Все мы прекрасно знаем, что отрываясь хотя бы на пять минут от «потока», приходится примерно с полчаса возвращаться «обратно в код».
Я сам никогда не отказывал в помощи коллегам, но всегда приучал команду к тому, что задавать вопросы тимлиду нужно только в том случае, когда уже изучен гугл и техническая документация, а ответа не найдено. Было время, когда я говорил «ок, давай погуглим вместе — а вот и ответ на твой вопрос, читай».
Да, заказчик не должен разбираться в айти. Но он должен уметь корректно составить бизнес-требования. При этом он должен понимать: любое изменение формулировки требований на середине этапа разработки скажется на сроках, поэтому внятно формулировать свои требования нужно с самого начала.
Дополню: в компаниях покрупнее менеджеры должны выращиваться из технических специалистов, иначе они просто не будут понимать бед команды разработчиков, аналитиков, тестировщиков и документаторов.
Возможно, задаю слишком очевидный вопрос, просто хочу лучше понять, что вы имеете в виду.
Приведите пожалуйста пример из практики, когда становится понятно, что коммуникации внутри команды нужно улучшать?
Как планировать, если заказчик сообщил о задаче сегодня, а сделана она должна быть вчера?
По возможности лучше отказаться от сотрудничества с таким заказчиком. Поверьте, чудаков не большинство.
Что делать, если фича еще не спроектирована полностью, но сроки жмут так, что надо начать кодить хоть что-то?
Не нужно «хоть что-то». Чревато архитектурными ошибками, а в будущем — вкручиванием новых костылей-фиксов в старый фундамент. Время, затраченное на исправление этих косяков в ядре, легко можно потратить на написание новых функциональных блоков.
В реальности ТЗ не будет идеальным. Скорее всего что-то будет не продумано. И времени на детализацию, конечно, нет.
Согласен. Для выхода из этой нелепой ситуации я обычно работаю по такой цепочке:
— сначала от заказчика добиваемся бизнес-требований (даже в самом запущенном случае они легко помещаются на распечатанный лист А4);
— потом принимаем решение о том, нужна ли аналитическая проработка, ТЗ, проектная документация. Если нет — сразу начинаем проектировать и реализовывать, если да, то чуть погодя.
В спорных случаях решающую роль играет утвержденный текст бизнес-требования. И от того, насколько четко и понятно они были сформулированы, зависит в целом успех работ по направлению.
Меньше восьми часов работать вполне можно, больше — уже перебор.
Если на разработчика сваливается гора критичных задач или он каждый раз тонет в коде, разбирая баги, это повод задуматься: а все ли хорошо с проектом?
И другой момент, но только поймите меня правильно: работать — не обязательно означает «выполнять должностные обязанности от звонка до звонка». Читать документацию и литературу, саморазвиваясь как IT-специалист, тоже можно на работе. Но если этого не получается, а жадный до информации мозг хочет ее получить, приходится заниматься IT в нерабочее время. А как же спорт, семья, хобби?
Нет, я не лентяй и тоже когда-то упарывался, работая по 12-16 часов, но потом сравнил свою производительность и понял, что приличную часть этого времени просто туплю в монитор вместо того, чтобы решать задачи. Как следует выспался, переосмыслил все, что происходит, и стал выполнять ту же работу вчетверо быстрее. Теперь у меня есть свободное рабочее время, которое я вполне могу посвятить чтению и саморазвитию.
По моим ощущениям в фразу «пост капитанство» вкладывался смысл «таких статей много, не стоило ее писать». То есть статье здесь делать нечего.
У меня другое мнение.
Статья полезна. Кратко и емко перечислены тезисы, а развернуть их не составит труда. Я постараюсь выделить время и написать чуть более развернутую статью, дополнив мысли VaiMR. Уверен, многим из нас будет интересно.
Пост написан, прежде всего, не на нервах, а на печальном опыте.
Вместо того, чтобы критиковать сложившуюся «авральную» технологию разработки, автор поста предлагает конкретные решения. И лично я с большинством их них согласен.
Внимательно почитал статью и комментарии, в том числе и твой. Не соглашусь с тем, что пост — капитанство.
Я чуть меньше восьми лет участвую в разных проектах разработки и могу по опыту сказать, что в большинстве проектов действительно существует беда с менеджментом. Этот пост нужно распечатать для некоторых моих прошлых руководителей проектов и дать хорошенько вчитаться.
Ты просто не понял смысла статьи, но это не значит, что она плоха.
// если есть светофор, горящий зеленым светом или его нет, но мы находимся на главной дороге
// и ничто не предвещает беды
if ( ( ((traffic_light) and (traffic_light_color == GREEN)) or (main_road)) and (no_disaster))
SetSpeed (GetCurrentSpeed); // едем не сбавляя скорости
else
SetSpeed (0); // тормозим
Я — экстраверт и искренне люблю работать в живом общении. Но страшный минус — в том, что меня здорово выдирает из потока (и возвращает обратно очень не скоро), когда через каждые мохнадцать минут ко мне обязательно кто-нибудь подходит и что-то спрашивает.
Вообще, я считаю, удобство офисной/удаленной работы зависит больше не от *вертности человека, а от того, какие задачи он решает.
Согласен насчет удобства подсветки stdout (может вы именно это имели в виду?) и автодополнения a-la zsh.
В любом случае, я буду следить за развитием проекта. Интересно, что получится у автора в конце концов. Пока еще рано делать однозначные выводы, судя по одной лишь альфа-версии.
Консоль — это воплощение брутальной строгости, простоты, аскетизма; тот инструмент, в котором нет ничего лишнего.
В некоторых случаях использование текстового интерфейса полностью оправдано, и, честно говоря, я плохо понимаю реальный практический смысл тех красивостей, которые предлагает нам идея TermKit.
Удобство? Да вряд ли.
Красота? Да.
Польза от повседневного практического применения — около нуля.
0. Пять итераций для того, чтобы подвинуть надпись на пару пикселей (предварительно сделав нехитрые вычисления с учетом DPI) — действительно перебор.
Пункты 1 и 2 и 3 требований я бы завернул. Объяснил бы заказчику, что есть общепринятый стандарт, и если поведение программы в корне отличается от поведения операционной системы, это, мягко скажем, запутывает. Если не поймет — сформулировал бы так, что на второй раз до него бы точно дошло.
4. Сфоткать штаны, сделать цветопробу и соответствующим образом поменять фон. Клиент офигеет от внимательности, потом передумает (цвет соответствует, но не нравится), а мы выкатываем дополнительную трудоемкость и просим оплатить. В следующий раз клиент говорит себе: «да, ребята внимательные, делают то, что я прошу. Я в следующий раз буду думать прежде, чем просить — а вдруг самому не понравится?»
5. Накурите клиента, анимация будет работать и на бумаге.
6. Да, это повод не делать фичу, телепаты в отпуске.
7. Для таких экземпляров нужно чаще ставить босса в CC, вдруг переведутся.
Чтобы не допустить такой ситуации, достаточно было задать вопрос: «перенос нужен однократный или потребуется возможность повторного»? Чтобы задавать такие и подобные вопросы, согласитесь, нужен опыт и некоторая дотошность.
Формально: подписание технического акта означает согласие принимающей стороны с корректностью реализации. Трактовка требований неоднозначна. Здесь я полностью на стороне разработчика, но приложил бы максимум разумных усилий для того, чтобы сохранить лояльность заказчика.
Когда в начале своего становления как программиста я столкнулся с п.1, решил не заморачиваться и просто сменил проект. Нервы дороже.
Спихивание вины — это проблема людей. Стараюсь не связываться со «стрелочниками». К сожалению, не всегда получается.
Сейчас могу уверенно ответить с позиции этого самого супер-мэна. Здесь я вижу два объяснения:
1. возможно, он действительно эгоцентрист, либо страдает неуверенностью в себе и не хочет, чтобы кто-то набирался знаний и стал лучше него.
2. компания, зная его талант, старается выпользовать его на полную, закидывая задачами, и у него объективно (!) не хватает времени на то, чтобы оторваться от кода и понятно развернуто ответить. Все мы прекрасно знаем, что отрываясь хотя бы на пять минут от «потока», приходится примерно с полчаса возвращаться «обратно в код».
Я сам никогда не отказывал в помощи коллегам, но всегда приучал команду к тому, что задавать вопросы тимлиду нужно только в том случае, когда уже изучен гугл и техническая документация, а ответа не найдено. Было время, когда я говорил «ок, давай погуглим вместе — а вот и ответ на твой вопрос, читай».
Да, заказчик не должен разбираться в айти. Но он должен уметь корректно составить бизнес-требования. При этом он должен понимать: любое изменение формулировки требований на середине этапа разработки скажется на сроках, поэтому внятно формулировать свои требования нужно с самого начала.
Приведите пожалуйста пример из практики, когда становится понятно, что коммуникации внутри команды нужно улучшать?
По возможности лучше отказаться от сотрудничества с таким заказчиком. Поверьте, чудаков не большинство.
Что делать, если фича еще не спроектирована полностью, но сроки жмут так, что надо начать кодить хоть что-то?
Не нужно «хоть что-то». Чревато архитектурными ошибками, а в будущем — вкручиванием новых костылей-фиксов в старый фундамент. Время, затраченное на исправление этих косяков в ядре, легко можно потратить на написание новых функциональных блоков.
В реальности ТЗ не будет идеальным. Скорее всего что-то будет не продумано. И времени на детализацию, конечно, нет.
Согласен. Для выхода из этой нелепой ситуации я обычно работаю по такой цепочке:
— сначала от заказчика добиваемся бизнес-требований (даже в самом запущенном случае они легко помещаются на распечатанный лист А4);
— потом принимаем решение о том, нужна ли аналитическая проработка, ТЗ, проектная документация. Если нет — сразу начинаем проектировать и реализовывать, если да, то чуть погодя.
В спорных случаях решающую роль играет утвержденный текст бизнес-требования. И от того, насколько четко и понятно они были сформулированы, зависит в целом успех работ по направлению.
Если на разработчика сваливается гора критичных задач или он каждый раз тонет в коде, разбирая баги, это повод задуматься: а все ли хорошо с проектом?
И другой момент, но только поймите меня правильно: работать — не обязательно означает «выполнять должностные обязанности от звонка до звонка». Читать документацию и литературу, саморазвиваясь как IT-специалист, тоже можно на работе. Но если этого не получается, а жадный до информации мозг хочет ее получить, приходится заниматься IT в нерабочее время. А как же спорт, семья, хобби?
Нет, я не лентяй и тоже когда-то упарывался, работая по 12-16 часов, но потом сравнил свою производительность и понял, что приличную часть этого времени просто туплю в монитор вместо того, чтобы решать задачи. Как следует выспался, переосмыслил все, что происходит, и стал выполнять ту же работу вчетверо быстрее. Теперь у меня есть свободное рабочее время, которое я вполне могу посвятить чтению и саморазвитию.
У меня другое мнение.
Статья полезна. Кратко и емко перечислены тезисы, а развернуть их не составит труда. Я постараюсь выделить время и написать чуть более развернутую статью, дополнив мысли VaiMR. Уверен, многим из нас будет интересно.
Вместо того, чтобы критиковать сложившуюся «авральную» технологию разработки, автор поста предлагает конкретные решения. И лично я с большинством их них согласен.
Я чуть меньше восьми лет участвую в разных проектах разработки и могу по опыту сказать, что в большинстве проектов действительно существует беда с менеджментом. Этот пост нужно распечатать для некоторых моих прошлых руководителей проектов и дать хорошенько вчитаться.
Ты просто не понял смысла статьи, но это не значит, что она плоха.
Попробовал, понравилось. Рекомендую :)
Gorthauer87, спасибо!
Мне кажется, нормально они себя поведут.
Я — экстраверт и искренне люблю работать в живом общении. Но страшный минус — в том, что меня здорово выдирает из потока (и возвращает обратно очень не скоро), когда через каждые мохнадцать минут ко мне обязательно кто-нибудь подходит и что-то спрашивает.
Вообще, я считаю, удобство офисной/удаленной работы зависит больше не от *вертности человека, а от того, какие задачи он решает.
В любом случае, я буду следить за развитием проекта. Интересно, что получится у автора в конце концов. Пока еще рано делать однозначные выводы, судя по одной лишь альфа-версии.
В некоторых случаях использование текстового интерфейса полностью оправдано, и, честно говоря, я плохо понимаю реальный практический смысл тех красивостей, которые предлагает нам идея TermKit.
Удобство? Да вряд ли.
Красота? Да.
Польза от повседневного практического применения — около нуля.
Как вы считаете?
Прикол от Google для самых внимательных.