Возможно, мы упираемся в то же бутылочное горлышко, что и 10, и 30 лет назад - ничтожно малый процент людей любит/умеет писать технические задания (software requirements specifications) и даже читать их. Даже с помощью ИИ - допустим, постановщик (product owner) набросал основные требования → ИИ домыслил → постановщик прочитал и попросил ИИ что-то поправить, выпустил ТЗ → никто из людей, кроме постановщика, ТЗ не прочитал до конца => пользуйтесь и постарайтесь получать удовольствие от того, что получилось, впрочем, как и раньше было. Другими словами, есть опасение, что SDD будет возможно применить достаточно редко - при наличии компетентных постановщиков. И поэтому постановщики, а не синьоры будут грести деньги лопатой?
На мой взгляд, чтобы заголовок отражал содержание, его нужно изменить на "Схемы архитектуры как код". Почему? Потому что, говоря "Архитектура как код", мы обещаем, что при помещении кода в репозиторий запустятся какие-то автоматические процессы и архитектура системы изменится. Например, по аналогии с Инфраструктура как код (IaC).
Знаю западные компании, которые начали "оценки 360" примерно в 2005-м и закончили в 2012-м с выводами: "Это не помогает. Это отнимает много времени. Это сильно демотивирует людей." По моему скромному мнению, на сегодня эти "360" лишь имитация работы менеджментом и HR-ами.
А, извините, не понял.
В среднем моя статистика примерно такая: В офисе с 12 до 20:30. Из них обед 20 мин, полдник 20 мин, пинг-понг 20 мин, новости (не программистские) 20 мин. Отлучения в туалет и налить чая — мелочи, не учитываем.
Особого разброса от недели к неделе не было.
Когда-то пытался вести статистику и по нерабочим активностям, но бросил, не увидел смысла.
Бывает, 25 рабочих часов в неделю получается.
42 часа — это максимум. В последние годы получается обходиться без штурмовщины.
В общем, на не-работу времени достаточно остается.
Я веду подобный учёт около 30 лет.
Главная для меня цель — контролировать количество отработанных часов в неделю и месяц, «подпинывая» самого себя таким образом. По моему опыту, большинство программистов в офисах реально не отрабатывают и 100 часов в месяц, и поэтому они вряд ли хотят своё время измерять и рассказывать правду о своём напряженном труде :)
Сейчас учёт веду в таблице гугл, записываю каждый день, сколько над каким проектом работал.
Разбиение достаточно «крупно-блочное» — проекты (обычно приходится работать над двумя-тремя параллельно), обучение. До уровня отдельных задач в этой таблице не опускаюсь, для этого есть Redmine у заказчика.
В конце недели и месяца смотрю на суммарные цифры.
Я пытался ещё какую-то пользу из этих данных извлечь, анализ проводить. Максимум что могу посчитать — распределение времени по проектам. Это, кстати, очень помогает при оценке новых проектов.
В общем, моё резюме такое: пару минут в день не вредно на это потратить.
15 лет назад я видел похожую разработку на Visual Basic, это было голосовое меню для банка. Тогда всё уткнулось в:
— невозможность уместить на экране и в голове больше десяти квадратиков (т.е. не-программист всё равно не может справиться с задачей реального размера);
— отсутствие повторно используемых кусков;
— невозможность отладки;
— невозможность отследить историю изменений по системе контроля версий.
В общем, с тех пор у меня скепсис по поводу графических средств программирования :)
Возможно, мы упираемся в то же бутылочное горлышко, что и 10, и 30 лет назад - ничтожно малый процент людей любит/умеет писать технические задания (software requirements specifications) и даже читать их. Даже с помощью ИИ - допустим, постановщик (product owner) набросал основные требования → ИИ домыслил → постановщик прочитал и попросил ИИ что-то поправить, выпустил ТЗ → никто из людей, кроме постановщика, ТЗ не прочитал до конца => пользуйтесь и постарайтесь получать удовольствие от того, что получилось, впрочем, как и раньше было. Другими словами, есть опасение, что SDD будет возможно применить достаточно редко - при наличии компетентных постановщиков. И поэтому постановщики, а не синьоры будут грести деньги лопатой?
На мой взгляд, чтобы заголовок отражал содержание, его нужно изменить на "Схемы архитектуры как код". Почему? Потому что, говоря "Архитектура как код", мы обещаем, что при помещении кода в репозиторий запустятся какие-то автоматические процессы и архитектура системы изменится. Например, по аналогии с Инфраструктура как код (IaC).
Что-то у меня ernie.baidu.com говорит Service unavailable...
Знаю западные компании, которые начали "оценки 360" примерно в 2005-м и закончили в 2012-м с выводами: "Это не помогает. Это отнимает много времени. Это сильно демотивирует людей." По моему скромному мнению, на сегодня эти "360" лишь имитация работы менеджментом и HR-ами.
Ну да, если есть группы людей, то есть проблемы на уровне взаимодействия групп.
А делать-то что?
Метрики нужны везде, и в community тоже!
В среднем моя статистика примерно такая: В офисе с 12 до 20:30. Из них обед 20 мин, полдник 20 мин, пинг-понг 20 мин, новости (не программистские) 20 мин. Отлучения в туалет и налить чая — мелочи, не учитываем.
Особого разброса от недели к неделе не было.
Бывает, 25 рабочих часов в неделю получается.
42 часа — это максимум. В последние годы получается обходиться без штурмовщины.
В общем, на не-работу времени достаточно остается.
Главная для меня цель — контролировать количество отработанных часов в неделю и месяц, «подпинывая» самого себя таким образом. По моему опыту, большинство программистов в офисах реально не отрабатывают и 100 часов в месяц, и поэтому они вряд ли хотят своё время измерять и рассказывать правду о своём напряженном труде :)
Сейчас учёт веду в таблице гугл, записываю каждый день, сколько над каким проектом работал.
Разбиение достаточно «крупно-блочное» — проекты (обычно приходится работать над двумя-тремя параллельно), обучение. До уровня отдельных задач в этой таблице не опускаюсь, для этого есть Redmine у заказчика.
В конце недели и месяца смотрю на суммарные цифры.
Я пытался ещё какую-то пользу из этих данных извлечь, анализ проводить. Максимум что могу посчитать — распределение времени по проектам. Это, кстати, очень помогает при оценке новых проектов.
В общем, моё резюме такое: пару минут в день не вредно на это потратить.
— невозможность уместить на экране и в голове больше десяти квадратиков (т.е. не-программист всё равно не может справиться с задачей реального размера);
— отсутствие повторно используемых кусков;
— невозможность отладки;
— невозможность отследить историю изменений по системе контроля версий.
В общем, с тех пор у меня скепсис по поводу графических средств программирования :)