Comments 28
Что такое «стемминг»? Вам не кажется, что подобные слова затрудняют управление проектами?
С водителем автобуса аналогия плохая: они чаще всего ездят по одному и тому же маршруту, и этот маршрут очень хорошо знают. Сложности с планированием в основном возникают, когда маршрут не известен. С программистами тут ещё более интересно получается: если ты что-то уже делал, то нет смысла делать это второй раз, например окно авторизации делается только один раз, а потом оно просто есть, точно так же как и всяческие списки, сортировки и т.д. Если программист новый проект начинает с рисования окна авторизации, и написания quicksort'а, то гнать этого дармоеда поганой метлой.
Междугородные рейсы имеются в виду. Маршрут то они знают, а доедут или нет по нашим безпасным дорогам — нет. А как заранее узнать, подойдет библиотека под проект или нет — без детального уточнения требований это выяснить невозможно же.
Я некоторое время назад регулярно катался между Кропоткином, Краснодаром, Ростовом и Таганрогом. Однажды пришлось ехать на автобусе из Краснодара в Волгоград. Автобусы всегда укладывались в график, с точностью до минут. Никогда не слышал об обратном.
>А как заранее узнать, подойдет библиотека под проект или нет — без детального уточнения требований это выяснить невозможно же.
А вот это уже незнакомый «маршрут».
>А как заранее узнать, подойдет библиотека под проект или нет — без детального уточнения требований это выяснить невозможно же.
А вот это уже незнакомый «маршрут».
Наш водитель на вопрос — «когда приедем?» отвечал — «как приедем, так приедем» :)
Больше 10-раз ездит в старом спринтере из молдавии в германию. Разница во времени была в основном из-за таможни молдавии и украины, и то 1-3 часа, не больше
У неискушенного читателя может сложиться впечатление, что выбор правильного набора инструментов, существенно повышает вероятность успеха.
ИМХО, это не совсем так.
50 лет назад сложные программные системы создавались без wiki, трекеров, календарей с напоминалками и даже (о ужас!) с проектной документацией на бумаге. Несмотря на постоянное появление все новых и новых инструментов поддержки разработки, согласно статистике, приведенной Демарко, средняя производительность в программостроении растет всего лишь на 3-5% в год.
Это происходит от того, что 80% времени программист работает головой и только 20% руками. А для повышения производительности работы мозга инструментов пока не придумали. Так что потенциал повышения эффективности работы программистов при помощи инструментов не превышает 20%.
ЗЫ. Не забудьте учесть затраты на развертывание, освоение и поддержку инструментария.
ИМХО, это не совсем так.
50 лет назад сложные программные системы создавались без wiki, трекеров, календарей с напоминалками и даже (о ужас!) с проектной документацией на бумаге. Несмотря на постоянное появление все новых и новых инструментов поддержки разработки, согласно статистике, приведенной Демарко, средняя производительность в программостроении растет всего лишь на 3-5% в год.
Это происходит от того, что 80% времени программист работает головой и только 20% руками. А для повышения производительности работы мозга инструментов пока не придумали. Так что потенциал повышения эффективности работы программистов при помощи инструментов не превышает 20%.
ЗЫ. Не забудьте учесть затраты на развертывание, освоение и поддержку инструментария.
Спасибо! Согласен отчасти.
1) Сейчас программы вроде сложнее и больше по объему, чем unix времен 70-х на PDP-11. Хотя конечно писали тогда mutics… и вроде он даже работал… :-)
2) Рынок избалован сроками, ими давят, они сжимаются
3) Поэтому водопад, как самая правильная честная профессиональная программистская модель — вытесняется маркетинговыми agile и социальными геймерскими штуками и инструментами
Вот чтобы выжить в условиях, когда нужно выкатить на бой послезавтра, и объем МЕНЯЮЩЕЙСЯ информации зашкаливает — думаю как раз помогут боевые штык нож и калашников.
1) Сейчас программы вроде сложнее и больше по объему, чем unix времен 70-х на PDP-11. Хотя конечно писали тогда mutics… и вроде он даже работал… :-)
2) Рынок избалован сроками, ими давят, они сжимаются
3) Поэтому водопад, как самая правильная честная профессиональная программистская модель — вытесняется маркетинговыми agile и социальными геймерскими штуками и инструментами
Вот чтобы выжить в условиях, когда нужно выкатить на бой послезавтра, и объем МЕНЯЮЩЕЙСЯ информации зашкаливает — думаю как раз помогут боевые штык нож и калашников.
И согласен, что инструменты конечно — не главное. Возможность открыто общаться, обсуждать и дать возможность рискам всплывать — т.е. организационные вещи — не менее важны для успеха.
Вы рассматривали конфигурацию 1С: Документооборот ? Она позволяет реализовать многое из вашего списка и на мой взгляд является интересной альтернативой.
Мы используем unfuddle + pbworks. В связке работает отлично.
ИМХО, за исключением редких случаев, сравнение разработки софта с полетом на луну вообще говоря не правомочно. Большинство приложений, даже те, где много математики и бизнес-логики, не уж такие сложные. А те, которые большие и сложные пишутся не одной итерацией и не с одного плана. Да и в процессе есть много места для маневров.
Мы тут друг друга кормим байками про то, что мы делаем мега сложные продукты, что «оценить точно невозможно», «много рисков» и прочее так долго, что сами в них поверили. А это ни больше ни меньше отсутствие банальной дисциплины и боевого опыта. Это не проблема утилит, это проблема людей и их руководителей (вроде меня).
Кстати, если вы спросите водителя рейсового автобуса в Германии или Штатах сколько до следующей остановки — получите ответ с точностью до ± 10 мин. Так что есть, к чему стремиться. ;-)
Мы тут друг друга кормим байками про то, что мы делаем мега сложные продукты, что «оценить точно невозможно», «много рисков» и прочее так долго, что сами в них поверили. А это ни больше ни меньше отсутствие банальной дисциплины и боевого опыта. Это не проблема утилит, это проблема людей и их руководителей (вроде меня).
Кстати, если вы спросите водителя рейсового автобуса в Германии или Штатах сколько до следующей остановки — получите ответ с точностью до ± 10 мин. Так что есть, к чему стремиться. ;-)
+100500
Но я бы оставил вообще как причину только одну дисциплину
Боевой опыт помогает только тогда, когда все остальное не помогло, в особенности дисциплина, и поэтому приходится делать проект за 3 дня, который уже 2 месяца все никак и никуда.
Правда в этом случае опыт помогает тому, у кого он есть
А если бы была дисциплина, то опыт бы помог и тем, у кого нет опыта
ЗЫ А не, еще внутренняя бюрократия, когда вместо быстрого решения проводится 25 совещаний, где из пустого в порожнее переливаются одни и те же обсуждения. Хотя это тоже наверное к дисциплине
Но я бы оставил вообще как причину только одну дисциплину
Боевой опыт помогает только тогда, когда все остальное не помогло, в особенности дисциплина, и поэтому приходится делать проект за 3 дня, который уже 2 месяца все никак и никуда.
Правда в этом случае опыт помогает тому, у кого он есть
А если бы была дисциплина, то опыт бы помог и тем, у кого нет опыта
ЗЫ А не, еще внутренняя бюрократия, когда вместо быстрого решения проводится 25 совещаний, где из пустого в порожнее переливаются одни и те же обсуждения. Хотя это тоже наверное к дисциплине
Если честно, я как бы предполагал, что все мы обладаем опытом, выстроили дисциплину как в армии, команда сильная и все знают свое дело… и тут выходят ранее скрытые ограничения и риски:
— карьерная борьба
— ограничение памяти
— слишком много информации, которую нужно классифицировать, иначе смерть в конвульсиях спинного мозга
— много народу, всех не запоминаешь — а общаться нужно
— клиент меняет требования
— файлы нужно не только хранить, но и обмениваться и комментировать
и т.п.
— карьерная борьба
— ограничение памяти
— слишком много информации, которую нужно классифицировать, иначе смерть в конвульсиях спинного мозга
— много народу, всех не запоминаешь — а общаться нужно
— клиент меняет требования
— файлы нужно не только хранить, но и обмениваться и комментировать
и т.п.
В начале статьи же не написаны такие вводные :)
Если исходить из того, что у нас все хорошо с дисциплиной, то остается только процессы сделать нормальными — а тут поможет и этот набор средств, и любой другой, лишь бы в них уметь работать
Может стоит лучше расписать, чем поможет именно данный инструмент и как с ним работать, чтобы он помог.
Хотя я боюсь, что обычно все наоборот: и процессы есть (вроде), и средств полно — а толку нет, потому что нет дисциплины. И это самое сложное. После процессов.
Кстати, ко всем средствам я бы добавил очень важное требование — легкое изменение под требования процессов. Мы пока поставили процессы, раза три их меняли, а вместе с ними и процессы трекера. Но он позволяет это делать относительно быстро и просто. А если нет? :)
Если исходить из того, что у нас все хорошо с дисциплиной, то остается только процессы сделать нормальными — а тут поможет и этот набор средств, и любой другой, лишь бы в них уметь работать
Может стоит лучше расписать, чем поможет именно данный инструмент и как с ним работать, чтобы он помог.
Хотя я боюсь, что обычно все наоборот: и процессы есть (вроде), и средств полно — а толку нет, потому что нет дисциплины. И это самое сложное. После процессов.
Кстати, ко всем средствам я бы добавил очень важное требование — легкое изменение под требования процессов. Мы пока поставили процессы, раза три их меняли, а вместе с ними и процессы трекера. Но он позволяет это делать относительно быстро и просто. А если нет? :)
Согласен. Встречаются иногда фанатики процессов, получающие оргазм от процесса, а не от результата. И вытаскивать их в состояние профессиональной потенции, бодрости и дисциплины — крайне тяжело если возможно, с риском осадка на всю жизнь :-)
Наверно важнее всего люди. Люди, которые мотивированы и… подстраиваются друг под друга — в интересах компании. С такой командой, думаю, можно менять процессы, убирать их нафиг — но держать необходимые инструменты для коммуникаций, чтобы всем было просто проще. И в случае ядерной войны — команда будет так же слаженно работать и в постатомном мире в подвале и на корточках :-)
С другой стороны, иногда вводят процессы специально, чтобы сделать сотрудников обезличенными и взаимозаменяемыми — Макдональдс. Чтобы указывать на дверь при любой возможности :-) Тогда никакие инструменты не помогут — в этих концлагерях лучше вообще не работать, чтобы психику не повредить :-)
Наверно важнее всего люди. Люди, которые мотивированы и… подстраиваются друг под друга — в интересах компании. С такой командой, думаю, можно менять процессы, убирать их нафиг — но держать необходимые инструменты для коммуникаций, чтобы всем было просто проще. И в случае ядерной войны — команда будет так же слаженно работать и в постатомном мире в подвале и на корточках :-)
С другой стороны, иногда вводят процессы специально, чтобы сделать сотрудников обезличенными и взаимозаменяемыми — Макдональдс. Чтобы указывать на дверь при любой возможности :-) Тогда никакие инструменты не помогут — в этих концлагерях лучше вообще не работать, чтобы психику не повредить :-)
Использую Slack для чата внутри команды, Trello для задач, Google docs для общих документов, Screenhero для шаринга экрана.
Ожидаемо, что в блоге Битрикса описаны преимущества Битрикс24. Та же Вики для проектов там тоже есть. Хотя в целом хороший, функциональный сервис. Я, признаюсь, удивился.
Честно говоря, надеялся, что в статье таки будет то, о чем написано в начале:
Но ничего такого не нашел, никакого описания вообще никакой борьбы ни с чем
То, что нужен набор инструментов — это и так каждому понятно. Но почему именно таких, какие в статье, и чем же «трекер задач, лучше с поддержкой иерархии и бизнес-процессов» поможет лучше, чем просто трекер задач...?
Примечательно, что концентрация на борьбе с рисками и известными причинами проблем — неожиданно приносит огромную пользу. Скажу больше — именно устранение препятствий в некоторых современных методологиях (scrum) — и является гарантией достижения цели проекта.
Но ничего такого не нашел, никакого описания вообще никакой борьбы ни с чем
То, что нужен набор инструментов — это и так каждому понятно. Но почему именно таких, какие в статье, и чем же «трекер задач, лучше с поддержкой иерархии и бизнес-процессов» поможет лучше, чем просто трекер задач...?
Так известные риски и способы их устранения я и постарался описать:
— каша в требованиях -> лечится викой
— проблемы мозга по запоминанию информации -> трекер
— друпбоксы и бардак в почте -> фреймворк обмена файлами и сообщениями, лечится на Битрикс24
— страх -> корпоративная социальная сеть с возможностью писать чтобы все прочитали и топы полайкали
— хрен знает как ее зовут -> структура компании и тел. справочник
— потеря контроля за процессом и утопание в RSS -> лечится живой лентой
— каша в требованиях -> лечится викой
— проблемы мозга по запоминанию информации -> трекер
— друпбоксы и бардак в почте -> фреймворк обмена файлами и сообщениями, лечится на Битрикс24
— страх -> корпоративная социальная сеть с возможностью писать чтобы все прочитали и топы полайкали
— хрен знает как ее зовут -> структура компании и тел. справочник
— потеря контроля за процессом и утопание в RSS -> лечится живой лентой
Не, я боюсь, бОльшая часть из перечисленных проблем вообще никак не связана с техническими возможностями
Каша из требований будет и в вики тоже, если нет четкого понимания по структуре и составу требований. А если есть понимание — то хоть в почте, будет все хорошо. Хотя таки да, с вики легче в итоге, даже бардак легче делать :)
Трекер да, поможет — но только в качестве хранилища задач
Файлы и сообщения — да хоть где, лишь бы удобно было. А лучше без файлов
Про страх я не очень понял, а сбор лайков — это вообще вряд ли к процессу управления относится
Живая лента — вообще не понял, чем она может помочь
Но! Это все средства, причем для организации любого процесса, хоть с рисками, хоть без
Но даже имея все эти средства, риск того, что все это не поможет — никак не меньше, чем без средств.
Потому что на самом деле важно другое (ИМХО, из опыта):
1. Дисциплина
2. Правильное управление всеми этими процессами
3. Дисциплина
Вот об этом бы поговорить и обменяться опытом, хорошим и плохим
Каша из требований будет и в вики тоже, если нет четкого понимания по структуре и составу требований. А если есть понимание — то хоть в почте, будет все хорошо. Хотя таки да, с вики легче в итоге, даже бардак легче делать :)
Трекер да, поможет — но только в качестве хранилища задач
Файлы и сообщения — да хоть где, лишь бы удобно было. А лучше без файлов
Про страх я не очень понял, а сбор лайков — это вообще вряд ли к процессу управления относится
Живая лента — вообще не понял, чем она может помочь
Но! Это все средства, причем для организации любого процесса, хоть с рисками, хоть без
Но даже имея все эти средства, риск того, что все это не поможет — никак не меньше, чем без средств.
Потому что на самом деле важно другое (ИМХО, из опыта):
1. Дисциплина
2. Правильное управление всеми этими процессами
3. Дисциплина
Вот об этом бы поговорить и обменяться опытом, хорошим и плохим
«нужен трекер задач, лучше с поддержкой иерархии и бизнес-процессов»можно еще рассмотреть Mantis
нужна иерархия компании с телефонным справочником и поискомwiki страничка со структурированным списком ссылок на странички юзеров вполне справится
Все очень здорово пока не столкнешься с техподдержкой Битрикса. Мы платим немалые деньги ежегодно за техподдержку, и вот настает тот долгожданный случай, когда приходится написать в техподдержку, у нас получается примерно раз в год, потому, что чаще просто нервы не выдержат.
Составляю заявку, прикладываю логи, лицензионный код, чтобы на заявку не упал чугунный болт и жду!
Через 2 часа ожидания и нервных нажатий F5, портал то не работает, люди ждут, замечаю приписочку «Максимальное время реакции на обращение – 6 рабочих часов.».
Ну ОК, будем ждать, 6 часов не неделя. К половине девятого вечера ответа не обнаруживаю, начинаю изучать страничку дальше, и вот найден ответ: «Рабочие часы считаются с 10 до 19 по московскому времени. В субботу, воскресенье и официальные праздничные дни РФ техподдержка не работает.»
Ну ладно сам виноват, умел бы читать, не стал бы писать заявку в 14 часов пятницы.
Приходит понедельник и на страничке появляется ответ специалиста, он спрашивает, а стоит ли галочка напротив неработающей опции. Пишу ответ, что ясенпень стоит, и опять жду несколько часов ответа. К сожалению караулить ответ постоянно не могу, в итоге получается за день ответить только на 1-2 вопроса «специалиста».
В итоге проблема, которая не стоит и 20 минут времени выливается в месяц.
На кой после этого, нам все эти плюшки от Битрикса?
Составляю заявку, прикладываю логи, лицензионный код, чтобы на заявку не упал чугунный болт и жду!
Через 2 часа ожидания и нервных нажатий F5, портал то не работает, люди ждут, замечаю приписочку «Максимальное время реакции на обращение – 6 рабочих часов.».
Ну ОК, будем ждать, 6 часов не неделя. К половине девятого вечера ответа не обнаруживаю, начинаю изучать страничку дальше, и вот найден ответ: «Рабочие часы считаются с 10 до 19 по московскому времени. В субботу, воскресенье и официальные праздничные дни РФ техподдержка не работает.»
Ну ладно сам виноват, умел бы читать, не стал бы писать заявку в 14 часов пятницы.
Приходит понедельник и на страничке появляется ответ специалиста, он спрашивает, а стоит ли галочка напротив неработающей опции. Пишу ответ, что ясенпень стоит, и опять жду несколько часов ответа. К сожалению караулить ответ постоянно не могу, в итоге получается за день ответить только на 1-2 вопроса «специалиста».
В итоге проблема, которая не стоит и 20 минут времени выливается в месяц.
На кой после этого, нам все эти плюшки от Битрикса?
Sign up to leave a comment.
Управление программными проектами — наизнанку