Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
Может быть фича и хорошая, но прочитав readme не захотелось столько всего устанавливать, да бы запустить приложение)
Не уверен, что можно статически прилинковать Gtk# (которому к тому же стал не так давно нужен еще и Gtk2 рантайм — для меня это было открытием, когда я попытался собрать под Windows), в интернетах пишут, что можно dll-ки таскать, но это тоже вариант так себе. Под Windows кстати (к слову) нельзя сделать bundle (исполняемый со всеми библиотеками файл) и для Mono из-за LGPL (поэтому собирал студией).
Пытался закинуть в архив оба рантайма, но на гуглосайтах лимит на файлы в 20 мегабайт. Поэтому сделал как сейчас.
Пытался закинуть в архив оба рантайма, но на гуглосайтах лимит на файлы в 20 мегабайт. Поэтому сделал как сейчас.
Зачем вам на Win32 запускать Mono? Кладёте рядом с приложением либы Gtk#, этого достаточно.
Я и собирал студией, чтобы Моно был не нужен. Рантайм класть рядом с приложением dll'ками я счел слегка некрасивым решением.
Поскольку дома я под линуксом, то для проверки поставил чистую хрюшу SP3 с .Net Framework 4, на нее поставил Gtk2-рантайм, затем Gtk# — и заработало. Без Gtk2-runtime не работает, так как начиная с какой-то версии Gtk# отвязали, вот уж не знаю почему и для меня это явилось откровением.
Поскольку дома я под линуксом, то для проверки поставил чистую хрюшу SP3 с .Net Framework 4, на нее поставил Gtk2-рантайм, затем Gtk# — и заработало. Без Gtk2-runtime не работает, так как начиная с какой-то версии Gtk# отвязали, вот уж не знаю почему и для меня это явилось откровением.
Спасибо за интересную модель и подробное её описание.
Я со временем пришел в выводу, что любое «управление проектами» это не про софт. Точнее про софт, но не более, чем на одну десятую. 90% это процессы. Пока нет процесса любой софт бесполезен.
Будущее за софтом, который будет помогать выстраивать процессы.
Я со временем пришел в выводу, что любое «управление проектами» это не про софт. Точнее про софт, но не более, чем на одну десятую. 90% это процессы. Пока нет процесса любой софт бесполезен.
Будущее за софтом, который будет помогать выстраивать процессы.
Софт естественно далеко не главное в УП. Тем не менее, наблюдал много раз, как софтом подменяют процессы. «Купим проджект и будем управлять проектами».
С другой стороны, процесс в настоящее время невозможен без инструмента — считать конечный срок проекта суммами дат по табличкам тоже не каждый захочет. В этом смысле процесс будет более качественным с инструментом. С правильным инструментом можно ответить именно на те вопросы, которые были заданы, а не на те, на которые умеет инструмент отвечать.
Пост скорее о том, что если есть понимание об управлении проектами — сделайте себе инструмент из подручных средств. Это будет лучше, чем возня с освоением какого-нибудь решения, и чем круче оно, тем оно скорее менее (!!) всего подходит. Взять хотя бы MS Project Server — вот обсчет портфеля там такой и никакой другой. Если захотите узнать, сколько заработаете на проектах — не узнаете, только «вклад в стратегию».
С другой стороны, процесс в настоящее время невозможен без инструмента — считать конечный срок проекта суммами дат по табличкам тоже не каждый захочет. В этом смысле процесс будет более качественным с инструментом. С правильным инструментом можно ответить именно на те вопросы, которые были заданы, а не на те, на которые умеет инструмент отвечать.
Пост скорее о том, что если есть понимание об управлении проектами — сделайте себе инструмент из подручных средств. Это будет лучше, чем возня с освоением какого-нибудь решения, и чем круче оно, тем оно скорее менее (!!) всего подходит. Взять хотя бы MS Project Server — вот обсчет портфеля там такой и никакой другой. Если захотите узнать, сколько заработаете на проектах — не узнаете, только «вклад в стратегию».
Мне вот показалось, что это эдакое изобретение собственного велосипеда. Мой личный опыт говорит о том, что обычно решение «сделать свое, родное» вызвано не отсутствием на рынке подходящих инструментов, а неумением ими пользоваться и нежеланием разбираться.
Я искренне не могу понять зачем надрывать пупок и работать без выходных и праздников вместо того, чтобы просто один раз взять и разобраться досконально с какой-нибудь существующей системой? С той же Jira. Там есть вообще все, только успевай бабки на счет заносить.
Очень часто встречалась в моей практике ситуация (в том числе и с моим участием), когда изначально заточенный, например, под Scrum инструмент отбрасывался как неподходящий только лишь потому, что на самом деле никто из команды понятия не имеет о том как работает Scrum и как им пользоваться. Очень легко, когда что-то не получается, обвинить в этом именно инструмент, а не себя любимого. Мне стоило больших усилий, чтобы заметить эту черту в себе и переломить ее. А многие так и не замечают, так и перебирают десятки рабочих хороших инструментов и в итоге приходят к выводу, что «надо просто написать свое и не париться».
С другой стороны, не могу поспорить с тем, что разработка своего инструмента очень хорошо помогает разобраться со всеми тонкостями выбранных методик и подходов. Но как по мне это довольно дорогой опыт, можно ведь дешевле достичь тех же результатов.
Я искренне не могу понять зачем надрывать пупок и работать без выходных и праздников вместо того, чтобы просто один раз взять и разобраться досконально с какой-нибудь существующей системой? С той же Jira. Там есть вообще все, только успевай бабки на счет заносить.
Очень часто встречалась в моей практике ситуация (в том числе и с моим участием), когда изначально заточенный, например, под Scrum инструмент отбрасывался как неподходящий только лишь потому, что на самом деле никто из команды понятия не имеет о том как работает Scrum и как им пользоваться. Очень легко, когда что-то не получается, обвинить в этом именно инструмент, а не себя любимого. Мне стоило больших усилий, чтобы заметить эту черту в себе и переломить ее. А многие так и не замечают, так и перебирают десятки рабочих хороших инструментов и в итоге приходят к выводу, что «надо просто написать свое и не париться».
С другой стороны, не могу поспорить с тем, что разработка своего инструмента очень хорошо помогает разобраться со всеми тонкостями выбранных методик и подходов. Но как по мне это довольно дорогой опыт, можно ведь дешевле достичь тех же результатов.
Вам показалось.
Я про проекты достаточно знаю, из профильного образования еще 8 лет назад полученного, из практики проектного управления на разных позициях (аналитик, пм, сотрудник ОУП, нач. отдела инвест. анализа, зам. дир.), и естественно, из изучения инструментов и хороших практик, многие из которых, начиная с PMBoK еще 2-ой версии я применял, и даже без софта. Что касается софта, то я его пересмотрел и русского, и английского, и всякого, и поработал наверное с десяточкой (в Jira есть очень мало всего, что касается УП, каким оно бывает в своём объеме, посмотрите например Spider Project для контраста).
И пришел к выводу, что лучше своё, читайте внимательнее, если есть понимание что такое проектное управление. Если нет понимания — то следует его обретать, а затем — пилить своё. В чистом виде я не видел 100% гибкого или 100% водопадного подхода ни в одном бизнесе. И для разных бизнесов годятся разные и инструменты и практики, но ничто из них не используется на 100%, и часто приходилось видеть что помимо применения этого одного инструмента/практики, дополнительно используется что-то еще. О чем это говорит?
О том, что надо ходить путями, которые за тебя кто-то сделал? Или всё же асфальтировать уже протоптанные дорожки (как советует теория организации?). И вообще можно было просто сказать, что вас не убедил, ровно так же, как и вы меня :)
Я считаю что бизнесы уникальны, даже если это 1С-франчайзи. И если бизнес построен на проектах, то явно это из-за денег, а не из-за того, чтобы быть правильными по применяемой методике. Приносят прибыли или убытки не используемые методы (можно при любой методике провалить проект), а характер их применения в обстоятельствах, релевантных для бизнеса. Поэтому свой метод и свой инструмент эффективнее решения, которое было сделано универсальным. Зачем платить за то, что не подходит?
Я про проекты достаточно знаю, из профильного образования еще 8 лет назад полученного, из практики проектного управления на разных позициях (аналитик, пм, сотрудник ОУП, нач. отдела инвест. анализа, зам. дир.), и естественно, из изучения инструментов и хороших практик, многие из которых, начиная с PMBoK еще 2-ой версии я применял, и даже без софта. Что касается софта, то я его пересмотрел и русского, и английского, и всякого, и поработал наверное с десяточкой (в Jira есть очень мало всего, что касается УП, каким оно бывает в своём объеме, посмотрите например Spider Project для контраста).
И пришел к выводу, что лучше своё, читайте внимательнее, если есть понимание что такое проектное управление. Если нет понимания — то следует его обретать, а затем — пилить своё. В чистом виде я не видел 100% гибкого или 100% водопадного подхода ни в одном бизнесе. И для разных бизнесов годятся разные и инструменты и практики, но ничто из них не используется на 100%, и часто приходилось видеть что помимо применения этого одного инструмента/практики, дополнительно используется что-то еще. О чем это говорит?
О том, что надо ходить путями, которые за тебя кто-то сделал? Или всё же асфальтировать уже протоптанные дорожки (как советует теория организации?). И вообще можно было просто сказать, что вас не убедил, ровно так же, как и вы меня :)
Я считаю что бизнесы уникальны, даже если это 1С-франчайзи. И если бизнес построен на проектах, то явно это из-за денег, а не из-за того, чтобы быть правильными по применяемой методике. Приносят прибыли или убытки не используемые методы (можно при любой методике провалить проект), а характер их применения в обстоятельствах, релевантных для бизнеса. Поэтому свой метод и свой инструмент эффективнее решения, которое было сделано универсальным. Зачем платить за то, что не подходит?
Да, с этим всем я согласен. У меня не было цели обвинить вас в неумении применять имеющиеся инструменты, я просто описал типичную ситуацию, в которую сам не раз попадал. Мне по наивности казалось, что я просто мало знаю и не до конца во всем разобрался, раз существующие инструменты кажутся мне неполными или неудобными. Хотя, сомнения в существовании и вообще в возможности их реализации меня никогда не покидали :)
Отчасти и я с вами согласен — инструменты становятся все изощреннее (и даже дешевле), и их на рынке уже избыток. Та же jira — не так уж и плоха для трекинга. Однако принять решение о старте она не поможет. Мне на самом деле кроме упомянутого Спайдера нравится еще несколько — stakepoint.com/ например (сейчас не знаю как его попробовать, но когда его разрабатывали, его еще можно было скачать), да даже банальный MS Project. Я просто зацепился за растраненную (в моей практике с чем сталкивался) ситуацию, когда планируют одним, а трекают другим, а потом менеджеры сидят в нескольких системах и каждый день нажимают одни и те же кнопки лишний раз.
Это происходит потому что бизнес ставит задачи и вопросы, на которые ни Agile, ни предварительное планирование водопадом, ни инструменты поддерживащие их, ответить по отдельности не способны. Поэтому концепция «женить» сама напрашивается. Женить можно по-разному. В одном месте где работал, к примеру, — из базы проджекта выгружали в Excel и работали с ним. Где-то просто заставляли менеджеров актуализировать обе системы и контролировали (либо начальство смотрит в одну, а менеджер для исполнителей использует другую — и это ситуация постоянная! что меня и сподвигло написать этот пост).
Например, ответ на следующие два вопроса одновременно не даст ни один инструмент, поддерживающий agile:
1. Сколько заработаем прибыли с проекта,
2. Когда заработаем эту прибыль.
С другой стороны привычные ганнт-диаграмные софтины по УП не могут толком сказать в каком состоянии проект и почему он в таком состоянии, и более того, в нём много излишнего для исполнителей (вы когда-нибудь отчитывались в проджекте как исполнитель задачи?.. упаси боже).
Вот в чем моя печаль. И более того… какая-то у меня уверенность, что не будет такого решения, которое всех бы устроило. Потому что у кого-то бизнес по выполнению заказов, у кого-то по разработке своих продуктов, у кого-то и то и другое, а у четвертых вообще только внутренние проекты. Поэтому я и пишу, что характер бизнеса первичен в определении проектного и метода и инструмента. И написать своё при наличии человека, который сможет написать ТЗ, как правило гораздо проще и дешевле: даже если это веб-страничка по учету времени на рабочем месте.
Я вот сейчас призадумался, и посчитал, в скольки местах я видел собственные решения.
Крупная компания (банковский софт) — внедряли проджект со скрипом,
Интегратор — проджект с выгрузкой в Excel,
Многопрофильная ИТ-компания (сервис, разработка и пр.) — своё на 1С,
Торговая компания — своё на Excel,
Международный холдинг — своё на Excel + проджект,
Компания со своими продуктами для гос. учреждений — своё вебовское + разные,
Веб-студия — своё вебовское + трекер,
Гейм-девелопмент — зоопарк.
По сути, все что-то пилят для себя, как минимум для какой-нибудь отчетности, либо имеют скрип и зоопарк с приседаниями по актуализации. И я подумал, это не потому что все поголовно не умеют пользоваться проджектом или жирой. А просто потому что в них есть излишки и недостатки для конкретного бизнеса.
Это происходит потому что бизнес ставит задачи и вопросы, на которые ни Agile, ни предварительное планирование водопадом, ни инструменты поддерживащие их, ответить по отдельности не способны. Поэтому концепция «женить» сама напрашивается. Женить можно по-разному. В одном месте где работал, к примеру, — из базы проджекта выгружали в Excel и работали с ним. Где-то просто заставляли менеджеров актуализировать обе системы и контролировали (либо начальство смотрит в одну, а менеджер для исполнителей использует другую — и это ситуация постоянная! что меня и сподвигло написать этот пост).
Например, ответ на следующие два вопроса одновременно не даст ни один инструмент, поддерживающий agile:
1. Сколько заработаем прибыли с проекта,
2. Когда заработаем эту прибыль.
С другой стороны привычные ганнт-диаграмные софтины по УП не могут толком сказать в каком состоянии проект и почему он в таком состоянии, и более того, в нём много излишнего для исполнителей (вы когда-нибудь отчитывались в проджекте как исполнитель задачи?.. упаси боже).
Вот в чем моя печаль. И более того… какая-то у меня уверенность, что не будет такого решения, которое всех бы устроило. Потому что у кого-то бизнес по выполнению заказов, у кого-то по разработке своих продуктов, у кого-то и то и другое, а у четвертых вообще только внутренние проекты. Поэтому я и пишу, что характер бизнеса первичен в определении проектного и метода и инструмента. И написать своё при наличии человека, который сможет написать ТЗ, как правило гораздо проще и дешевле: даже если это веб-страничка по учету времени на рабочем месте.
Я вот сейчас призадумался, и посчитал, в скольки местах я видел собственные решения.
Крупная компания (банковский софт) — внедряли проджект со скрипом,
Интегратор — проджект с выгрузкой в Excel,
Многопрофильная ИТ-компания (сервис, разработка и пр.) — своё на 1С,
Торговая компания — своё на Excel,
Международный холдинг — своё на Excel + проджект,
Компания со своими продуктами для гос. учреждений — своё вебовское + разные,
Веб-студия — своё вебовское + трекер,
Гейм-девелопмент — зоопарк.
По сути, все что-то пилят для себя, как минимум для какой-нибудь отчетности, либо имеют скрип и зоопарк с приседаниями по актуализации. И я подумал, это не потому что все поголовно не умеют пользоваться проджектом или жирой. А просто потому что в них есть излишки и недостатки для конкретного бизнеса.
Опять же, приходим к мысли, что универсального решения нет.
Даже если это два брата близнеца — перевозчика, конкурента в одной и той же отрасли и с одной и той же ЦА на одном и том же маршруте.
Один автоперевозчик быстрее и чаще, чем конкурент, приезжает на одну и ту же остановку — получит ли он прибыль больше конкурента, затратит ли он меньше, оптимальны ли отношения расходов к доходам…
Даже если это два брата близнеца — перевозчика, конкурента в одной и той же отрасли и с одной и той же ЦА на одном и том же маршруте.
Один автоперевозчик быстрее и чаще, чем конкурент, приезжает на одну и ту же остановку — получит ли он прибыль больше конкурента, затратит ли он меньше, оптимальны ли отношения расходов к доходам…
Вы, наверное, утрируете? :) Вы про операции говорите. В плане проектов даже два перевозчика могут отличаться очень сильно. В одном владелец хочет расширяться, в другом не хочет. Одному надо посчитать, сколько принесет закупка новых автобусов, а другому — нет. В любом случае это не проектный, а сервисный бизнес.
Для сервисного бизнеса — взять например обыкновенное такси — также существует множество решений. Но в отличие от проектов, которые уникальны, операции там не настолько уникальны, чтобы их нельзя было автоматизировать до некоторой степени универсально. Управление сервисными операциями не всегда требует изощренных практик, наличие которых для проектов делает (или не делает) непригодными программные инструменты.
Если взять ИТ как сервис (ITIL и прочее), то и здесь ситуация несколько отличная от проектов, потому что это операции, стандартизирование которых редко мешает бизнесу быть гибким. Колл-центр он и есть колл-центр, ему не надо управлять будущим, к нему бизнес не предъявляет противоречивых (с точки зрения разнообразия методов решения) вопросов.
Для сервисного бизнеса — взять например обыкновенное такси — также существует множество решений. Но в отличие от проектов, которые уникальны, операции там не настолько уникальны, чтобы их нельзя было автоматизировать до некоторой степени универсально. Управление сервисными операциями не всегда требует изощренных практик, наличие которых для проектов делает (или не делает) непригодными программные инструменты.
Если взять ИТ как сервис (ITIL и прочее), то и здесь ситуация несколько отличная от проектов, потому что это операции, стандартизирование которых редко мешает бизнесу быть гибким. Колл-центр он и есть колл-центр, ему не надо управлять будущим, к нему бизнес не предъявляет противоречивых (с точки зрения разнообразия методов решения) вопросов.
Все-таки это выглядит несколько странно. Какими бы ни были специфические требования конкретного бизнеса, эти инструменты создавались и развиваются точно такими же бизнесами. И я сильно сомневаюсь, что тот же Atlassian можно упрекнуть в незнании проектной специфики и непонимании требований их клиентов.
Другой вопрос, что ту же Jira нужно затачивать под свои процессы, чтобы работа с ней не доставляла лишней головной боли. Но она даже в стоковом варианте намного лучше excel :)
На мой взгляд, проблема все-таки не в инструменте, а в подходе. Agile методологии хорошо работают, когда правильно реализованы. Даже водопад имеет право на жизнь, если оставить попытки быть гибкими и допускать вольности. Я это понял, когда мы пытались внедрить CCPM. Тоже хотели сделать свою интерпретацию, подтянуть его к своим условиям и т.п. Но в итоге получилась какая-то ерунда. Еще раз вдумчиво ознакомившись с теорией мы пришли к выводу, что методология работает именно в том виде, в каком ее задумал автор. Любые попытки сделать шаг в сторону приведут к фейлу.
В общем, я убежден, что при правильных процессах и полном понимании сути используемой методологии на рынке полно годнейших инструментов, которые без проблем будут работать сразу из коробки.
Другой вопрос, что ту же Jira нужно затачивать под свои процессы, чтобы работа с ней не доставляла лишней головной боли. Но она даже в стоковом варианте намного лучше excel :)
На мой взгляд, проблема все-таки не в инструменте, а в подходе. Agile методологии хорошо работают, когда правильно реализованы. Даже водопад имеет право на жизнь, если оставить попытки быть гибкими и допускать вольности. Я это понял, когда мы пытались внедрить CCPM. Тоже хотели сделать свою интерпретацию, подтянуть его к своим условиям и т.п. Но в итоге получилась какая-то ерунда. Еще раз вдумчиво ознакомившись с теорией мы пришли к выводу, что методология работает именно в том виде, в каком ее задумал автор. Любые попытки сделать шаг в сторону приведут к фейлу.
В общем, я убежден, что при правильных процессах и полном понимании сути используемой методологии на рынке полно годнейших инструментов, которые без проблем будут работать сразу из коробки.
Какими бы ни были специфические требования конкретного бизнеса, эти инструменты создавались и развиваются точно такими же бизнесами.
Как раз таки немного другими. Иначе все сидели бы на Jira и не занимались бы её кастомизацией.
И я сильно сомневаюсь, что тот же Atlassian можно упрекнуть в незнании проектной специфики и непонимании требований их клиентов.
До момента старта проекта (неважно по какой практике) происходит очень много вещей. Jira мне не скажет, какой вариант проекта лучше, какой NPV у проекта, наконец при каких условиях проект будет убыточным. Когда я утвержу все эти показатели со спонсором, последний весьма хотел бы видеть прогресс относительно утвержденного, а не относительно какого-то там бэклога.
Что касается упомянутого CCPM, и методов в задуманном виде — все они (и CCPM) имеют ограниченную область применения, и ни один из них не отвечает на все вопросы, которые бизнес может поставить, сразу. И вопросы не экзотика какая-нибудь, а банально одновременно, повторюсь, сколько-когда-получим-в-чистом-виде + какие-отклонения-имеем-и-почему + где-можно-оптимизировать-портфель.
Я смотрю с точки зрения не одного проекта, а бизнеса который хочет быть в плюсе с рядом проектов. На одном проекте вполне возможно и Trello хватит. И да кстати, про Excel. Вот он как раз тот инструмент, который может ответить на все три вопроса одновременно. Но неудобно, к сожалению.
при правильных процессах и полном понимании сути используемой методологии на рынке полно годнейших инструментов, которые без проблем будут работать сразу из коробкиЯ о том и говорю, что коробки сделаны под те подходы, которые описаны кем-то для абстрактных проектов абстрактных компаний в вакууме. А в конкретной компании всё совсем конкретно, и совсем не так как в коробке.
И вообще это какие-то идеальные обстоятельства — процессы как задумано автором. Где такое видели? На коротком промежутке производственной цепочки такое возможно еще, но стоит подняться на ступеньку выше или ниже, сделать шаг влево или вправо по этой цепочке, как коробка превращается в тыкву. И что, если автор метода завтра передумает и напишет «Критическая цепь-17: издание дополненное и исправленное»?
Даже у Тойоты бывают косяки, что уж о нас смертных. Процесс сам по себе никому не нужен, нужен только его продукт, а специфика продукта всегда меняет и проект, и процесс, я не видел контрпримеров. Если процесс не настраивается, такой как CCPM например, — то это говорит только о том, что его область применимости очень узкая (CCPM и TOC так вообще вещи в себе), и он не подходит к вашему продукту и средствам его производства.
И я вообще говорил вовсе не о практиках! А об инструментах, облегчающих применение сложившихся в компании практик. Если вы уверены, что адаптации работы к практикам, а не наоборот, как считаю я, есть «правильный» путь, то я считаю что путь наоборот, есть «экономически эффективный» (для тех кто с осознанием подходит, а не с фанатизмом).
И еще небольшая лирика про CCPM. Надо понимать, что CCPM это (один из) способов снизить риски проектов, сильно завязанных на сроки людей. Всего лишь, и больше он ничего не даёт. Вот поднимать его на флаг (как это в Нске вообще кстати заметил происходит) — затея так себе, поскольку имеет смысл развивать управление рисками в целом по проектам и по компании системно. Это одна из привычных черт русского бизнеса, бессмысленного и беспощадного, искать там где светло, а не там где потеряли. Это как бы раз.
Как бы два это то, что когда днём с фонарём найдут что-нибудь, начинается фанатение (особенно если какие консультанты поконсультируют). Вот гибкие методы! Да я был в АкадемГородке, когда там выступал какой-то канадец-мессия Agile, еще в 2004 году. Вливал в уши красоту гибких методов, какие они на тот момент были. Тоже черта наших, брать не разбираясь практики — и отстраивать процессы ради красоты диаграмм. Та же беда и с ИСО была, кто ей только не болел. 1С чего только стоит.
Я думал прошли уже в России времена экспериментаторства, и наступили времена экономических решений — и где-то ведь они наступили. Правильным является то, что приводит к максимальному чистому результату. Вот это я понимаю управление. Если бизнес развлекается внедрениями, а не оптимизацией, значит у него много шальных денег, а это всегда ситуация временная.
Я не говорю, что практики надо отметать в принципе. Я говорю что практики надо выбирать и использовать сообразно обстоятельствам. Тогда это будет система управления, а не кучка подходов и сборище закупленного софта для решения местечковых задач. Тогда и нужно будет свое программное решение. Но для этого как раз надо иметь осознание что идет действие не скачанным из интернета рецептам, а по соображениям, которые исходят из опыта. Надо иметь определенную уверенность. Если её нет, то тогда копировать (а не адаптировать) — самый путь.
Как бы два это то, что когда днём с фонарём найдут что-нибудь, начинается фанатение (особенно если какие консультанты поконсультируют). Вот гибкие методы! Да я был в АкадемГородке, когда там выступал какой-то канадец-мессия Agile, еще в 2004 году. Вливал в уши красоту гибких методов, какие они на тот момент были. Тоже черта наших, брать не разбираясь практики — и отстраивать процессы ради красоты диаграмм. Та же беда и с ИСО была, кто ей только не болел. 1С чего только стоит.
Я думал прошли уже в России времена экспериментаторства, и наступили времена экономических решений — и где-то ведь они наступили. Правильным является то, что приводит к максимальному чистому результату. Вот это я понимаю управление. Если бизнес развлекается внедрениями, а не оптимизацией, значит у него много шальных денег, а это всегда ситуация временная.
Я не говорю, что практики надо отметать в принципе. Я говорю что практики надо выбирать и использовать сообразно обстоятельствам. Тогда это будет система управления, а не кучка подходов и сборище закупленного софта для решения местечковых задач. Тогда и нужно будет свое программное решение. Но для этого как раз надо иметь осознание что идет действие не скачанным из интернета рецептам, а по соображениям, которые исходят из опыта. Надо иметь определенную уверенность. Если её нет, то тогда копировать (а не адаптировать) — самый путь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Waterban, PlanTrack, GtkSharp и другие смешные словосочетания — пара мыслей о том, почему стоит сделать решение по УП под себя