Обилие технологий не должно смущать. Выбрать фреймворк под задачу в 2020, очевидно, сложнее, чем в 2000 — но, сделав правильный выбор, развернуть решение и получить результат зачастую удается в разы быстрее.
p.s. вдогонку к готовым cms типа вордпресса, если вдруг хочется попроще в плане архитектуры — любой статический генератор (gatsby, etc.), который даже на условные github pages из коробки встает (а это значит — без геморроя весь CI, мало ли в резюме показать :) ), решает описанную задачу.
Я не утверждаю, что расчеты неверные; мне была интересна статистика компании, профиль которой — разработка инструментов тестирования.
И да, у нас в основном TDD, а как при таком подходе выделить чистое (и потенциально сэкономленное) время на поиск и устранение ошибок — не представляю.
Как-то по умолчанию считается, что в команде из 10 программистов каждый гарантированно тратит в год на поиск и исправление багов по 156 часов (1 560 часов суммарно).
А что, по вашей статистике среднестатистический проект и правда требует такого объема баголовных часов? И более того, из этого времени 100% закрывается анализатором кода?
Когда я не знаю, что именно мне нужно, и в первый раз вижу какую-то прикольную высокотехнологичную штуку (привет, мэдроботс, лефутур, etc.), то лично мне нужно определенное время на посмотреть, походить кругами, подумать.
В условиях островка, когда вокруг толпа народа, все какое-то непонятно-прозрачное в закрытых витринах, нет нормального контакта с продавцом — мне как-то… неуютно, что ли. Поэтому с большим удовольствием захожу в отдельные магазинчики (и да, иногда покупаю там что-то :) ), но ни разу ничего не брал ничего серьезного в «островках».
Если это будет общий список задач (т.е. всех задач со всех досок и списков), да еще и с возможностью накладывать фильтры по тем же 1) доскам, 2) спискам, 3) датам — то можно и с группировкой, так сразу решается множество проблем. Например, поиск всех задач, связанных с определенной темой независимо от даты…
Но изначально я имел ввиду просто лист «задача — дата», или в упрощенном виде «задача» по заранее выбранной дате/периоду.
А есть возможность как-то, кроме календаря (т.е. в самом интерфейсе пинтаска) посмотреть «все задачи на сегодня» (или на период)?
При том, что задачи болтаются в разных списках или даже досках — что-то вроде туду на период.
Или это будет как раз в том календаре, который будет после приведения карточек в идеальное состояние?
Главное, чтобы разработчик не говорил так одновременно. Я, к сожалению, сталкивался с такими случаями.
Конечно, низкая дисциплина сотрудников — это не повод внедрять систему, а повод поработать с персоналом. Но, согласитесь, уровень ответственности при наличии системы трекинга (в любом виде) повышается.
Наличие автоматических рассылок-напоминаний, наглядного интерфейса с красными значками напротив просроченных задач (или же задач, требующих указания комментариев и статуса), а также самого факта наличия системы ввода и контроля проектной информации сильно упрощает работу менеджера.
«Автоматически делается системой» не сам ввод данных (хотя частично можно сделать и так — авторасчеты статусов на основе данных из других систем), а сбор, анализ и демонстрация текущего статуса менеджеру.
Просто если без ppm менеджер вынужден 1) пинать сотрудников о регулярных отчетах и 2) сводить и анализировать их по каким-то параметрам, то при автоматизации, по крайней мере, становится попроще со вторым пунктом.
Вы, безусловно, правы с той точки зрения, что внедрение комплексного ppm-решения не стоит начинать только ради перевода всей базы данных по проектам в многофункциональную систему, т.е. мигрировать с простенького трекинга в нечто более масштабное и заканчивать на этом.
Но это чаще всего — первый шаг. И один из самых болезненных, поскольку простоты для участников процесса уже нет (одно дело — внести одной строчкой информацию по проекту или задаче, и совсем другое — заполнить те же взаимосвязи, оценку трудозатрат, добавить сверху риски и т.д.), и при этом наглядной выгоды от таких действий еще нет — ни нормальной отчетности, ни статистики, ретроспективу сделать невозможно.
О портфеле, как о некоторой совокупности отдельных проектов, вообще речи не идет — ведь отсутствует даже полноценный контроль на уровне проектов.
Поэтому, на мой взгляд, верно отмечен сам тренд — необходимость, начиная с определенного момента, переходить на следующий уровень контроля и отчетности, т.е. на комплексную ppm, но для начала — на проектном, а не портфельном уровне.
Кстати, в примавере и clarity инструменты портфельного анализа все же достаточно серьезные — как минимум, система прав доступа, агрегация данных и планирование в обе стороны (от портфеля вниз или от проекта вверх), а также инструментарий балансировки проектов портфеля и what-if анализ на портфельном уровне. Есть еще что-то критичное, что отсутствует в этих продуктах?
P.S. Если есть опыт по быстрому переходу от упрощенного тайм-ресурс-контроля до уровня портфельного управления — с удовольствием бы познакомился или почитал.
Если я правильно понял, одно из опасений автора — то, что серьезный физически/медицинский/химический [...] инструментарий пишут специально (не)обученные физики/медики/химики.
Есть у меня подозрение, что, например, систему моделирования белков пишут не врачи, подучившие плюсы по третьему изданию Страуструпа, а специально обученные разработчики — которые могут вообще не иметь медицинского образования, зато умеют читать грамотно составленное тем же медиком ФС, в котором нет медицинской теории и предположений, зато есть четкие алгоритмы бизнес-уровня и формулы, расчет которых нужно реализовать программно.
Если я правильно понял, одно из опасений автора — то, что серьезный физически/медицинский/химический [...] инструментарий пишут специально (не)обученные физики/медики/химики.
Есть у меня подозрение, что, например, систему моделирования белков пишут не врачи, подучившие плюсы по третьему изданию Страуструпа, а специально обученные разработчики — которые могут вообще не иметь медицинского образования, зато умеют читать грамотно составленное тем же медиком ФС, в котором нет медицинской теории и предположений, зато есть четкие алгоритмы бизнес-уровня и формулы, расчет которых нужно реализовать программно.
В таком случае можно попробовать рассказать про «проект по [разработке/внедрению/развертыванию продукта] для компании [отрасли/сферы/определенных размеров]».
У меня был лишь один случай, когда вообще нельзя было упоминать содержание проекта (по причине того, что он был первым в стране по данному профилю, и его упоминание в любом виде однозначно указало бы на заказчика, исполнителя и т.д.
The main challenge is assuring Kickstarter that this is a joke and not a serious project.
As proof, the goal has been set high enough to make successful funding almost impossible.
Мне все ж интересно две вещи:
— кто определяет, что человек обладает достаточной компетенцией для занятия этим самым всем, чем захочет? Коллективное решение проекта, в котором хочет участвовать сотрудник, или все же кто-то типа руководителя проекта?
— неужели в девелоперских компаниях не находится работы, которой в среднем 1) мало кто хочет заниматься и при этом 2) ее достаточно много? Речь конечно именно о процессе разработки, а не бухгалтерии или какой-нибудь АХС.
p.s. вдогонку к готовым cms типа вордпресса, если вдруг хочется попроще в плане архитектуры — любой статический генератор (gatsby, etc.), который даже на условные github pages из коробки встает (а это значит — без геморроя весь CI, мало ли в резюме показать :) ), решает описанную задачу.
И да, у нас в основном TDD, а как при таком подходе выделить чистое (и потенциально сэкономленное) время на поиск и устранение ошибок — не представляю.
А что, по вашей статистике среднестатистический проект и правда требует такого объема баголовных часов? И более того, из этого времени 100% закрывается анализатором кода?
Когда я не знаю, что именно мне нужно, и в первый раз вижу какую-то прикольную высокотехнологичную штуку (привет, мэдроботс, лефутур, etc.), то лично мне нужно определенное время на посмотреть, походить кругами, подумать.
В условиях островка, когда вокруг толпа народа, все какое-то непонятно-прозрачное в закрытых витринах, нет нормального контакта с продавцом — мне как-то… неуютно, что ли. Поэтому с большим удовольствием захожу в отдельные магазинчики (и да, иногда покупаю там что-то :) ), но ни разу ничего не брал ничего серьезного в «островках».
Но изначально я имел ввиду просто лист «задача — дата», или в упрощенном виде «задача» по заранее выбранной дате/периоду.
При том, что задачи болтаются в разных списках или даже досках — что-то вроде туду на период.
Или это будет как раз в том календаре, который будет после приведения карточек в идеальное состояние?
Конечно, низкая дисциплина сотрудников — это не повод внедрять систему, а повод поработать с персоналом. Но, согласитесь, уровень ответственности при наличии системы трекинга (в любом виде) повышается.
Наличие автоматических рассылок-напоминаний, наглядного интерфейса с красными значками напротив просроченных задач (или же задач, требующих указания комментариев и статуса), а также самого факта наличия системы ввода и контроля проектной информации сильно упрощает работу менеджера.
«Автоматически делается системой» не сам ввод данных (хотя частично можно сделать и так — авторасчеты статусов на основе данных из других систем), а сбор, анализ и демонстрация текущего статуса менеджеру.
Просто если без ppm менеджер вынужден 1) пинать сотрудников о регулярных отчетах и 2) сводить и анализировать их по каким-то параметрам, то при автоматизации, по крайней мере, становится попроще со вторым пунктом.
Вы, безусловно, правы с той точки зрения, что внедрение комплексного ppm-решения не стоит начинать только ради перевода всей базы данных по проектам в многофункциональную систему, т.е. мигрировать с простенького трекинга в нечто более масштабное и заканчивать на этом.
Но это чаще всего — первый шаг. И один из самых болезненных, поскольку простоты для участников процесса уже нет (одно дело — внести одной строчкой информацию по проекту или задаче, и совсем другое — заполнить те же взаимосвязи, оценку трудозатрат, добавить сверху риски и т.д.), и при этом наглядной выгоды от таких действий еще нет — ни нормальной отчетности, ни статистики, ретроспективу сделать невозможно.
О портфеле, как о некоторой совокупности отдельных проектов, вообще речи не идет — ведь отсутствует даже полноценный контроль на уровне проектов.
Поэтому, на мой взгляд, верно отмечен сам тренд — необходимость, начиная с определенного момента, переходить на следующий уровень контроля и отчетности, т.е. на комплексную ppm, но для начала — на проектном, а не портфельном уровне.
Кстати, в примавере и clarity инструменты портфельного анализа все же достаточно серьезные — как минимум, система прав доступа, агрегация данных и планирование в обе стороны (от портфеля вниз или от проекта вверх), а также инструментарий балансировки проектов портфеля и what-if анализ на портфельном уровне. Есть еще что-то критичное, что отсутствует в этих продуктах?
P.S. Если есть опыт по быстрому переходу от упрощенного тайм-ресурс-контроля до уровня портфельного управления — с удовольствием бы познакомился или почитал.
Есть у меня подозрение, что, например, систему моделирования белков пишут не врачи, подучившие плюсы по третьему изданию Страуструпа, а специально обученные разработчики — которые могут вообще не иметь медицинского образования, зато умеют читать грамотно составленное тем же медиком ФС, в котором нет медицинской теории и предположений, зато есть четкие алгоритмы бизнес-уровня и формулы, расчет которых нужно реализовать программно.
Есть у меня подозрение, что, например, систему моделирования белков пишут не врачи, подучившие плюсы по третьему изданию Страуструпа, а специально обученные разработчики — которые могут вообще не иметь медицинского образования, зато умеют читать грамотно составленное тем же медиком ФС, в котором нет медицинской теории и предположений, зато есть четкие алгоритмы бизнес-уровня и формулы, расчет которых нужно реализовать программно.
У меня был лишь один случай, когда вообще нельзя было упоминать содержание проекта (по причине того, что он был первым в стране по данному профилю, и его упоминание в любом виде однозначно указало бы на заказчика, исполнителя и т.д.
Печаль :(
Насколько быстро выходит на крейсерскую скорость?
— кто определяет, что человек обладает достаточной компетенцией для занятия этим самым всем, чем захочет? Коллективное решение проекта, в котором хочет участвовать сотрудник, или все же кто-то типа руководителя проекта?
— неужели в девелоперских компаниях не находится работы, которой в среднем 1) мало кто хочет заниматься и при этом 2) ее достаточно много? Речь конечно именно о процессе разработки, а не бухгалтерии или какой-нибудь АХС.