по мотивам http://slon.ru/blogs/sgodin/post/457995/
Как думаете - актуально ?
Как думаете - актуально ?
13 комментариев | Оставить комментарий
Максим Крамаренко
Да, я думаю я смогу описать несколько use case-ов, где TrackStudio по сравнению с e-mail будет сильно лучше. До сих пор этого не сделали, т.к. считали, что если клиент "добрался" до TrackStudio, то зачем трекер нужен он уже знает и его большинство open source трекеров не устраивают.
Второй важный момент, которые не все понимают - это преимущества workflow-систем перед web-версией коллективного todo-list-а. Как мне кажется, важность workflow сейчас серьезно недооценивается массовым пользователем. На Западе массовое "прозрение" и рост спроса на workflow-системы был году в 2004-2006, но то ли до нас оно не докатилось еще, то ли это уже вторая волна пошла.
Второй важный момент, которые не все понимают - это преимущества workflow-систем перед web-версией коллективного todo-list-а. Как мне кажется, важность workflow сейчас серьезно недооценивается массовым пользователем. На Западе массовое "прозрение" и рост спроса на workflow-системы был году в 2004-2006, но то ли до нас оно не докатилось еще, то ли это уже вторая волна пошла.
То, workflow, которое "на западе" тут стоит, просто монструозные нагроможнедия, которые никто не использует, пока не начинают гнать в него палкой. Без консалтинга и готовых решений ничего не идёт.
До начала реализации TrackStudio мы использовали mantis, много экспериментировали в плане организации работы и мучились из-за невозможности быстро перенастраивать систему. Т.е. мы работали не по какой-то конкретной и стабильной методологии, а сначала автоматизировали "бардак", потом смотрели что плохо, потом меняли процессы, добавили триггеров, проверок, опять меняли процессы.
Уже потом мы узнали, что такой подход называется business process automation (BPA):
http://en.wikipedia.org/wiki/Business_process_automation
===
The BPM camp asserts that before any process can be automated, it is necessary to define (often at a very strategic level or enterprise-wide) all of the business processes running inside an organisation. From this the processes can be re-defined and where necessary optimised, including automation.
The BPA camp state that until a process is automated, there is no real value in analysing and defining it, and that the cycle of business change is so rapid that there simply isn’t time to define every process before choosing which ones to address with automation, and that delivering immediate benefits creates more value.
===
Целью всех этих экспериментов было не упростить жизнь сотрудникам и сделать удобнее :-), а добиться соблюдения формальных правил. Например, если просто сказать сотрудникам "при закрытии бага нужна описывать что было сделано" - в 50% случаев комментарий может быть типа "все исправил", придется переоткрывать задачу и выяснять что же было сделано. Команда у нас тогда была весьма распределенной и у меня не хватало терпения постоянно пинать за несоблюдение формальных правил. Степень бардака потихоньку увеличивалась, поэтому очень хотелось систему, которая бы просто не позволяла закрывать задачи с подобными комментариями (причем подобные правила должны были относительно легко добавляться/удаляться).
Т.е. смысл всех этих детальных описаний workflow - в возможности один раз сказать как есть/должно быть и переложить на систему контроль соблюдения правил. Если правила оказались плохими - работа сразу встанет, но не будет ситуации, когда все якобы соблюдают правила, но на деле все правила всем "по барабану", а начальство вообще ни на что не влияет и узнает все последним.
Уже потом мы узнали, что такой подход называется business process automation (BPA):
http://en.wikipedia.org/wiki/Business_process_automation
===
The BPM camp asserts that before any process can be automated, it is necessary to define (often at a very strategic level or enterprise-wide) all of the business processes running inside an organisation. From this the processes can be re-defined and where necessary optimised, including automation.
The BPA camp state that until a process is automated, there is no real value in analysing and defining it, and that the cycle of business change is so rapid that there simply isn’t time to define every process before choosing which ones to address with automation, and that delivering immediate benefits creates more value.
===
Целью всех этих экспериментов было не упростить жизнь сотрудникам и сделать удобнее :-), а добиться соблюдения формальных правил. Например, если просто сказать сотрудникам "при закрытии бага нужна описывать что было сделано" - в 50% случаев комментарий может быть типа "все исправил", придется переоткрывать задачу и выяснять что же было сделано. Команда у нас тогда была весьма распределенной и у меня не хватало терпения постоянно пинать за несоблюдение формальных правил. Степень бардака потихоньку увеличивалась, поэтому очень хотелось систему, которая бы просто не позволяла закрывать задачи с подобными комментариями (причем подобные правила должны были относительно легко добавляться/удаляться).
Т.е. смысл всех этих детальных описаний workflow - в возможности один раз сказать как есть/должно быть и переложить на систему контроль соблюдения правил. Если правила оказались плохими - работа сразу встанет, но не будет ситуации, когда все якобы соблюдают правила, но на деле все правила всем "по барабану", а начальство вообще ни на что не влияет и узнает все последним.
Я это всё знаю.
Просто, если функционал продавать, надо, чтоб у клиента глаза не разбегались.
Просто, если функционал продавать, надо, чтоб у клиента глаза не разбегались.
Да, работа не встанет. Это не Япония со своими хитрыми методами. На систему плюнут и будут пилить на коленке напильником.
У нас локально эта проблема решилась с помощью 2 нововведений:
1) Можно делать только те задачи, которые внесены в систему и назначены на соот. сотрудника.
2) Зарплата выплачивается по результатам отчета TrackStudio о затраченном времени на задачи.
Т.е. даже если сотрудник решит делать что-то втайне от системы, то ему потом придется "списать" это время путем занесения отработанных часов на какую-то другую задачу. В результате начальство и коллеги увидят, что человек день маялся с задачей, которую можно было бы сделать за час. Даже если никто ничего не скажет, то карма у человека ухудшится, увеличение зарплаты будет отложено, а список кандидатов на увольнение - расширен. Выглядеть в глазах окружающих белым и пушистым при отсутствии активности в системе довольно затруднительно.
1) Можно делать только те задачи, которые внесены в систему и назначены на соот. сотрудника.
2) Зарплата выплачивается по результатам отчета TrackStudio о затраченном времени на задачи.
Т.е. даже если сотрудник решит делать что-то втайне от системы, то ему потом придется "списать" это время путем занесения отработанных часов на какую-то другую задачу. В результате начальство и коллеги увидят, что человек день маялся с задачей, которую можно было бы сделать за час. Даже если никто ничего не скажет, то карма у человека ухудшится, увеличение зарплаты будет отложено, а список кандидатов на увольнение - расширен. Выглядеть в глазах окружающих белым и пушистым при отсутствии активности в системе довольно затруднительно.
Зарплата выплачивается по результатам отчета TrackStudio о затраченном времени на задачи
В Германии подобное строжайше запрещено.
Да и разговор был о клиентах, а не о том, как программисты изыскивают резервы в своих продуктах
В Германии подобное строжайше запрещено.
Да и разговор был о клиентах, а не о том, как программисты изыскивают резервы в своих продуктах
