Я по всем пунктам — за второй вариант, за менее формальный, за более коллективный, за более творческий, не убивающий инициативу…
Программирование ведь командная игра(ну как и в принципе сама жизнь), верно?) Так давайте поощрять «командность»=)
Такая структура этих «10-ти комментариев» (я имею ввиду что каждый делится на две ветки), зачем?) чтобы собрать в каждой под-ветке тех кто за нее?) так в таком случае обсуждения не выйдет, вроде как) а если отписываться и в той ветке, и в той, то на выходе, по идее, получится много перекрестных ссылок)
Такая структура чтобы:
1. Была возможность проголосовать за подход по конкретному критерию
2. Была возможность добавить аргумент к конкретному критерию
Ну и потом — у нас нет стандартной структуры такого обсуждения. Возможно, есть вариант организовать иначе.
Я придумал такой вариант и решил поэкспериментировать с ним.
Давайте не забывать, что форма общения на этом ресурсе не формализирована) Мне кажется структура тут не нужна), структуру можно было бы получить потом, просуммировав уже комментарий каждого, составив некий отчет)
И не стоит забывать) кто ваша целевая аудитория, это люди которые не согласны мириться с чем-то, просто потому, что «есть правило, и нужно ему следовать», если есть правило, оно должно быть рациональным, оно должно что-то упрощать, оно должно помогать решать задачу)
Ваших аргументов в пользу этой структуры явно не достаточно.
Что у такой структуры комментариев есть такого, чего нет у всех других статей?)Чего мы не видим?)
Состояния реализации запланированных функций и ежедневных «статус-митингов» вполне достаточно и для тактического и для стратегического мониторинга хода проектов
у меня такое ощущение, что обсуждения с такой структурой вы не получите. единственный шанс получить нормальный фидбэк по интересующим вас вопросам — удалить пост (так как комментарии удалять нельзя). написать новый пост с таким же текстом, но без десятка излишних совершенно комментариев.
А как тогда голосовать по пунктам?
Я не утверждаю, что этот подход единственно верный. Я пробую.
И потом — что мешает вести свободную дискуссию здесь, ниже?
да, никакого негатива не было. предложили вам просто убрать эти комментарии.
как видите, с вашим подходом обсуждения/голосования вы не получили. хотя, думаю, многим тема интересна.
Мне кажется, что учет рабочего времени нужен, но команда не должна отвлекаться на него. Заполнять какие-то бумажки, отчеты.… Лучше автоматизировать процесс с помощью специальной программы учета и все.
Мне кажется, что метод Timesheeting на западе чаще называют Time Tracking. Мы на работе используем Time Tracker primaERP. Когда я запускаю по конкретной задаче таймер это мобилизует. Это в какой то степени «заставляет» лучше концентрироваться на конкретной задаче, если не хочешь увидеть в результатах нецелевое использование часов. Важно собирать статистику по использованному времени, чтобы понимать в каких пропорциях и на что оно тратится.
Об учёте времени в проектах разработки ПО