Описаны классические ошибки создателей доморощенных информационных систем:
1. Не прочитаны методички управления задачами от товарищей, которые пытались сделать это раньше тебя. То есть не знание теории управления вообще и методологии управления задачами в частности. Обычно это случается с молодыми программистами-отличниками, только что закончившими вуз и думающими, что они с нуля могут разработать любую информационную систему. Я встречал в своей жизни пару таких программеров, которые приходили в компанию и начинали писать свой аналог «1С», и лет через 5-10 их руководство обнаруживало, что работоспособной системы, как не было так и нет, закрывало эту лавочку и покупало «1С».
2. Пункт 2 сразу следует из пункта 1 — не знание методологии привело к реализации по принципу «все ставят поручения всем». Как следствие — неконтролируемый поток поручений. Есть простой, но фундаментальный принцип управления — «Поручения рядовому работнику может ставить только непосредственный начальник и никто больше». А начальнику — его начальник начальника и так далее.
3. Конкретно в моей компании — поручения начальнику отдела может отправлять либо его руководитель, либо «Владелец бизнес-процесса» (это отдельная история, что сначала желательно внедрить процессное управление, а затем уже в рамках «конкретного(!) бизнес-процесса» конкретные(!) люди могут раздавать в рамках своего процесса конкретного(!) вида поручения). А не каждый какое ему вздумается поручение кому угодно придумывает.
4. Поручения должны быть сформулированы по определенной методике (например SMART), а не по принципу «сделай то, не знаю что». И формулировка должна быть согласована тоже.
5. Для каждого поручения должно быть сформулировано ОБОСНОВАНИЕ, и не по принципу — «Хочу что бы было сделано», а по принципам «это поручение необходимо для достижения таких целей» или «это поручение необходимо для решение такой жизнено необходимой производственной задачи» и тому подобное. Оказывается сформулировать разумное обоснование не так-то просто и часть «хотелок» отваливается на этом этапе.
6. Плюс если поручение затрагивает соседние подразделения и/или соисполнители — необходимо их согласование. Плюс у поручения должны выставляться приоритеты и не создателем поручения, а кем-то другим (например, 5 уровней приоритета). И часть поручений (особенно 5-го приоритета) отмирают естественным путем — ведь к их исполнению можно приступить только после выполнения поручений с 4-ым приоритетом)))
7. Трудоемкость исполнения поручений должна оцениваться в «человека-часах» и эта трудоемкость тоже должна с кем-то согласовываться.
8. Обязателен некий «Календарь загрузки» исполнителя — если сумма поручений превышает 8 часов в день, все поручения (даже 1-го приоритета) автоматически сдвигаются по срокам, либо изменяется приоритет, либо исполнителю начинают платится сверхурочные, либо ещё что придумывается. Но загрузка работника, как непосредственными его обязанностями, так и приходящими поручениями, не может превышать некие разумные пределы.
9. Можно ещё добавить пунктов, но уже выше написанных хватит, чтобы понять: «С бухты-барахты хорошую систему управления задачами не напишешь.» Необходимо тщательная подготовка и проработка постановки задач, разработки ТЗ, опытно-промышленной обкатки первой версии и тому подобное…
Приезжайте)))
Понятно.
Просто подумалось, что может какой-то патриот Приморья))
Есть геопортал Приморья 188.170.233.213 развиваемый практически на голом энтузиазме((
Здравствуйте!
Почему выбран для примера Приморский край?
Вы из Приморья?
1. Не прочитаны методички управления задачами от товарищей, которые пытались сделать это раньше тебя. То есть не знание теории управления вообще и методологии управления задачами в частности. Обычно это случается с молодыми программистами-отличниками, только что закончившими вуз и думающими, что они с нуля могут разработать любую информационную систему. Я встречал в своей жизни пару таких программеров, которые приходили в компанию и начинали писать свой аналог «1С», и лет через 5-10 их руководство обнаруживало, что работоспособной системы, как не было так и нет, закрывало эту лавочку и покупало «1С».
2. Пункт 2 сразу следует из пункта 1 — не знание методологии привело к реализации по принципу «все ставят поручения всем». Как следствие — неконтролируемый поток поручений. Есть простой, но фундаментальный принцип управления — «Поручения рядовому работнику может ставить только непосредственный начальник и никто больше». А начальнику — его начальник начальника и так далее.
3. Конкретно в моей компании — поручения начальнику отдела может отправлять либо его руководитель, либо «Владелец бизнес-процесса» (это отдельная история, что сначала желательно внедрить процессное управление, а затем уже в рамках «конкретного(!) бизнес-процесса» конкретные(!) люди могут раздавать в рамках своего процесса конкретного(!) вида поручения). А не каждый какое ему вздумается поручение кому угодно придумывает.
4. Поручения должны быть сформулированы по определенной методике (например SMART), а не по принципу «сделай то, не знаю что». И формулировка должна быть согласована тоже.
5. Для каждого поручения должно быть сформулировано ОБОСНОВАНИЕ, и не по принципу — «Хочу что бы было сделано», а по принципам «это поручение необходимо для достижения таких целей» или «это поручение необходимо для решение такой жизнено необходимой производственной задачи» и тому подобное. Оказывается сформулировать разумное обоснование не так-то просто и часть «хотелок» отваливается на этом этапе.
6. Плюс если поручение затрагивает соседние подразделения и/или соисполнители — необходимо их согласование. Плюс у поручения должны выставляться приоритеты и не создателем поручения, а кем-то другим (например, 5 уровней приоритета). И часть поручений (особенно 5-го приоритета) отмирают естественным путем — ведь к их исполнению можно приступить только после выполнения поручений с 4-ым приоритетом)))
7. Трудоемкость исполнения поручений должна оцениваться в «человека-часах» и эта трудоемкость тоже должна с кем-то согласовываться.
8. Обязателен некий «Календарь загрузки» исполнителя — если сумма поручений превышает 8 часов в день, все поручения (даже 1-го приоритета) автоматически сдвигаются по срокам, либо изменяется приоритет, либо исполнителю начинают платится сверхурочные, либо ещё что придумывается. Но загрузка работника, как непосредственными его обязанностями, так и приходящими поручениями, не может превышать некие разумные пределы.
9. Можно ещё добавить пунктов, но уже выше написанных хватит, чтобы понять: «С бухты-барахты хорошую систему управления задачами не напишешь.» Необходимо тщательная подготовка и проработка постановки задач, разработки ТЗ, опытно-промышленной обкатки первой версии и тому подобное…