[SergeiK]

Я тут перечитал написанное. В режиме диалога нить теряется. Напишу вкратце, что я имел в виду.

 

Очень грубо, я имел в виду я следующее: нередко в компании нужен человек, который, в целом и общем, понимает, как работает весь IT, в плане технологий.

Как различные решения отвечают требованиям бизнеса, как они согласуются между собой, какие технологии используются для этих решений, какие надо менять, какие спокойно доживут свой век и прочее, прочее, прочее. И этот человек и будет архитектором предприятия. Очень хорошо, если такой человек еще и ведет документацию по этим вопросам (сам или контролируют этот вопрос).

В большой компании таких людей может быть много, но хорошо бы среди них иметь главного, который отвечает за все, в целом, перед бизнесом.

Не всегда такой человек есть, я думаю многие тут воочию видели ситуацию, когда никто не знает, как или зачем работает какая-то железка или софт или еще что-то...

 

Нередко такую роль выполняет технический руководитель, а то и сам руководитель небольшой компании.

С развитием компании руководителя перестает хватать и на управленческую работу и на технологическую, и он, или разрывается, не зная, за что хвататься первым, или сосредотачивается на чем-то одном, забывая про другую.

 

У меня есть ощущение, что Тимур эту роль тащит сам, и пытается разорваться, чтоб объять необъятное.

 

Поэтому я и написал, что Тимуру нужно определить одного человека, который будет отвечать за архитектуру его предприятия.

Для этого не обязательно сразу очень много знать, надо понимать направления и желать в этом направлении развиваться.

Указанные выше методологии - некий возможный ориентир, что есть в большой индустрии. Это не значит, что этот ориентир - обязательная цель, прочем уже на завтра.

Если какая-то методология не нравиться - нет никаких проблем работать по другой, или, вообще, придумать свою, идеальную для его компании.

Однако, какие-то базовые минимальные вещи по архитектуре было бы очень хорошо знать.

 

И именно об этом я и спрашивал: знает ли кто относительно небольшой и доступный вводный курс в архитектуру предприятия, который можно было бы посоветовать для более детального ознакомления, о чем вообще речь. Книгу или курс обучения, или еще что-то.

[SergeiK]

Я досконально не знаю, что такое EABOK, но взглянув на TOGAF, мне хватило полученных знаний по менеджменту в рамках моего университетского экономического образования,

чтоб понять что это.

А у Вас есть диплом экономфака ?

У меня есть диплом физика :). Но это было довольно давно.

Моего поверхностного взгляда не хватило, чтоб понять минимальные масштабы применимости данной методологии.

 

По полноценному внедрению ITIL масштабы должны быть велики, то есть под сотню людей в ИТ, ибо там только ролей за 30.

А вот внедрение отдельных элементов вполне себе оправдано и на средних масштабах.

 

Я полагаю, что может быть аналогично и в TOGAF, какие-то элементы применимы в масштабах сильно меньших, чем это разумно при полноценном внедрении.

 

Только не забываем, что аналитик и архитектор - это тоже разные люди и иногда друг с другом конфликтуют.

В случае Тимура - все должно быть в одном. И Энтерпрайз архитектор, и Солюшн и Инфрастракче, и BA и еще и PMO.

Ибо масштаб задач и компании не требует выделенных людей под всякую роль.

Ага, это еще хуже. Когда эти роли в одной голове конфликтовать начинают. Когда люди разные - хоть один у другого в 'слепые пятна' тыкает. А в одной голове - бррр... тоска и голова пухнет.

Только когда число таких людей растет, и они теряют возможность договорится. Плавали, знаем :).

В результате архитектура замерзает, ибо чтоб внести изменения, надо договориться со всем и соблюсти противоречивые требования.

 

Лучше пусть будет один, пусть не гений, пусть со слепыми пятнами, но работа будет идти, а не стоять, потому что двое уперлись рогами и не могут договорится.

[Тимур]

 

У меня есть ощущение, что Тимур эту роль тащит сам, и пытается разорваться, чтоб объять необъятное.

 

Поэтому я и написал, что Тимуру нужно определить одного человека, который будет отвечать за архитектуру его предприятия.

Для этого не обязательно сразу очень много знать, надо понимать направления и желать в этом направлении развиваться.

 

Прямой вопрос - прямой ответ.

 

У нас анархия. Куча систем, много заказчиков, много разработчиков. Центральной координации нет.

 

И я не могу декретно такого человека ввести. Нужно, чтобы такой человек выделился из тех, кто участвует в теме и убедил остальных, что всем будет лучше, если появится координатор

 

:-)

 

:-(

 

 

Вот поэтому и курсы. Я хочу отправить нескольких человек на обучение, в надежде что

- все проникнутся необходимостью культурного подхода

- появится кто-то кому будет интересно развиваться в этом направлении и он продвинется дальше остальных

- остальные не будут возражать, через чур уж горячо. Ну и при этом у всех будет некий единый язык в смысле управления проектами

[NN----NN]

Большая часть этих проблем будут решены только в случае ликвидации преприятия :-)))

 

Тимур, шутка не по Фрейду?

 

Помучившись несколько раз в структурах, которые к моменту моего прихода уже существовали два года или более, понял, что лучше всё делать правильно с самого начала (орг. структура д.б. наполнена и связана бизнес-процессами, на уровне сотрудников/специалистов заданы коммуникационные связи, прописаны права на запрос информации (кто даёт эту информацию и в какие сроки) и обязанности по предоставлению по запросу других (кто может запрашивать)).

 

Поэтому, совет может быть неожиданный, но подумай - не выстроить ли для части компании орг.структуру и бизнес-процессы заново - выделить этакий проектный офис. Выдвини/назначь руководителя. Может так?

[SergeiK]

 

У меня есть ощущение, что Тимур эту роль тащит сам, и пытается разорваться, чтоб объять необъятное.

 

Поэтому я и написал, что Тимуру нужно определить одного человека, который будет отвечать за архитектуру его предприятия.

Для этого не обязательно сразу очень много знать, надо понимать направления и желать в этом направлении развиваться.

Прямой вопрос - прямой ответ.

 

У нас анархия. Куча систем, много заказчиков, много разработчиков. Центральной координации нет.

Я помню, ты описывал. У меня нет уверенности, что этот вариант масштабируемый.

Но, в Политоте labi рекламировал труды Кропоткина по этому вопросу :).

 

 

И я не могу декретно такого человека ввести. Нужно, чтобы такой человек выделился из тех, кто участвует в теме и убедил остальных, что всем будет лучше, если появится координатор

:-)

 

:-(

 

Вот поэтому и курсы. Я хочу отправить нескольких человек на обучение, в надежде что

- все проникнутся необходимостью культурного подхода

- появится кто-то кому будет интересно развиваться в этом направлении и он продвинется дальше остальных

- остальные не будут возражать, через чур уж горячо. Ну и при этом у всех будет некий единый язык в смысле управления проектами

Я не могу посоветовать конкретные курсы, увы.

Но, лично мне кажется, что, все же, в твоем случае, требуемый координатор - это "архитектор", а не "руководитель проекта".

[Тимур]

Большая часть этих проблем будут решены только в случае ликвидации преприятия :-)))

 

Тимур, шутка не по Фрейду?

 

Помучившись несколько раз в структурах, которые к моменту моего прихода уже существовали два года или более, понял, что лучше всё делать правильно с самого начала (орг. структура д.б. наполнена и связана бизнес-процессами, на уровне сотрудников/специалистов заданы коммуникационные связи, прописаны права на запрос информации (кто даёт эту информацию и в какие сроки) и обязанности по предоставлению по запросу других (кто может запрашивать)).

 

Поэтому, совет может быть неожиданный, но подумай не выстроить ли для части компании орг.структуру и бизнес-процессы заново - выделить этакий проектный офис. Выдвини/назначь руководителя. Может так?

 

 

Может и так. А может и не так.

 

Черт его знает.

 

 

Давайте я вам, дорогие друзья, конкретный пример приведу. Ну просто чтобы разговор был предметней.

 

 

Сейчас перед нами стоит задача - поднять продающий коллцентр. Нужно обзовнить подключенных клиентов и им предложить допуслугу. OTT ТВ, если конкретно.

В рамках этой задачи, есть подзадача - организовать обзвон клиентской базы.

 

Можно не морочиться и раздать операторам выгрузки из базы. Нате обзванивайте. Собрать в какой-нибудь гуглдок - и уже через час начать работу.

Ну тут есть сразу вопросы.

 

Когда оператор обзавнивает клиентов - он тратит очень много времени на

- то чтобы выбрать кому будет звонить в следующией раз

- набор номера

- ожидание соединения

- оператору нужна пауза, чтобы прийти в себя после того, как его послали в очередной раз

 

Теоретически можно адово увеличить эффективность, если включить многопоточный обзвон - скажем по какому-то кучерявому алгоритму дозваниваться одновременно до десяти клиентов и раскидывать их по трем операторам.

 

А еще есть вопросы связанные с тем, что какая-то ведь часть клиентов скажет что-то типа "у меня муж в командировке", " мы подумаем, перезвоните в октябре" и т.д.

 

А может кто-то увидит пропущенный на мобильном и решит перезвонить?

 

А что если клиент сказал - "Конечно хочу ОТТ - всегда мечтал, пришлите мастера"

 

А может клиент скажет что-то типа "Вы офигели, у вас интернет работает через раз на третий - я вообще собираюсь отключаться"

 

 

ТО есть два направления улучшения

- организация автоматического обзвона

- интеграция с существующим пространством

 

 

Допустим мы понимаем, что в существующую систему эту хрень запихнуть сложно. Тогда нам нужна еще одна система

 

Она может быть или самописная или сторонняя система.

 

Если мы делаем стороннюю систему, то возникает вопрос - как с ней интегрироваться.

 

Как загружать данные , как получать отчеты, как хранить реакцию. Короче вопросов очень много.

 

Если же писать свою - то у нас получается еще одна система.

 

Может это и нормально - ну допишем модуль к нашей системе коллцентра. Но тогда нужно собирать требования к системе, внедрять, разбираться с багами и т.д.

Вести доработки. Там будут хотелки. Некоторые хотелки разумные. А некоторые неразумные. Как отличить первые от вторых?

 

А может все таки купить какую-нибудь систему, которая "умеет все из коробки, только нужно разобраться с мануалом"

 

 

А может быть (с учетом всего этого развлечения), плюнуть на все и сказать - торгуйте старым казцким способом, выгрузки+ телефон с кнопками + гуглдок

 

 

Как назвать человека, который может принять взвешенное решение по данному вопросу?

 

 

Это я еще не коснулся вопроса - а стоит ли делать свой коллцентр или проще и правильней отдать аутсорсерам, для которых это профильная деятельность

[jab]

Я помню, ты описывал. У меня нет уверенности, что этот вариант масштабируемый.

 

:-) Теперь представьте, что он описал 10 процентов лучшей части, а худшую стыдливо спрятал. :-)))

[Sonne]

Помучившись несколько раз в структурах, которые к моменту моего прихода уже существовали два года или более, понял, что лучше всё делать правильно с самого начала (орг. структура д.б. наполнена и связана бизнес-процессами, на уровне сотрудников/специалистов заданы коммуникационные связи, прописаны права на запрос информации (кто даёт эту информацию и в какие сроки) и обязанности по предоставлению по запросу других (кто может запрашивать)).

 

Как человек, который проработал где то в 5 различных компания разной структуры, разной величины и степени успешности, но строго в одной области телекома, могу авторитетно сказать. Не существует такого понятия, как "делать правильно". Если команда живет, зарабатывает, борется с конкурентами, то значит она уже делает правильно.

 

Вы совершаете ошибку "второй системы". Разработчик, у которого взлетела первая система, которую он смастерил как попало, вдруг решает что теперь то он опытный специалист и все сделает правильно. И во второй раз всегда наступает провал. Потому что залогом успеха первой системы часто бывает быстрота, гибкость, некотарая аморфность и непродуманность - то что делает ее адаптивной.

 

То что вы написали - это формализация крупной стабильной компании в фазе умирания. У меня

 

 

Поэтому, совет может быть неожиданный, но подумай - не выстроить ли для части компании орг.структуру и бизнес-процессы заново - выделить этакий проектный офис. Выдвини/назначь руководителя. Может так?

 

А зачем, если у Тимура анархическая структура управления? У него решения принимаются не командно-административно, а путем договоренностей и убеждений?

 

Как я понял, ему хочется прокачать скиллы лидеров групп, чтобы выделить более авторитетного товарища, который бы имел больше веса в принятии решений и могу бы взять на себя некоторые стратегические вопросы.

[Тимур]

Рома, ты - "мистер сущность"

[ttttt]

Как назвать человека, который может принять взвешенное решение по данному вопросу?

Смотрите, тут дело совсем не в таком человеке и не в его взвешенном решении. Дело именно в общем подходе к разработке. Вы хотите ответов на вопросы, на которые на данном этапе только гадалка может ответить. Ну какие могут быть разговоры о списках требований, пока не понятно, как оно вообще будет работать? Может там будут проблемы совсем другого рода, а не те, о которых вы сходу подумали, откуда вам знать? А может вообще вся разработка окажется дороже, чем то, во что вся эта попытка апсэлла выльется. No silver bullet Фрэда Брукса читали? Почитайте, это как раз об этом. Если можно не делать - лучше не делать, если нельзя - то лучше начинать с минимально возможного прототипа на скорую руку, пробовать и только потом уже делать нормально. А со временем станет понятно куда двигаться дальше и улучшать.

[Kirya]

Я досконально не знаю, что такое EABOK, но взглянув на TOGAF, мне хватило полученных знаний по менеджменту в рамках моего университетского экономического образования,

чтоб понять что это.

А у Вас есть диплом экономфака ?

У меня есть диплом физика :). Но это было довольно давно.

Моего поверхностного взгляда не хватило, чтоб понять минимальные масштабы применимости данной методологии.

 

По полноценному внедрению ITIL масштабы должны быть велики, то есть под сотню людей в ИТ, ибо там только ролей за 30.

А вот внедрение отдельных элементов вполне себе оправдано и на средних масштабах.

 

Я полагаю, что может быть аналогично и в TOGAF, какие-то элементы применимы в масштабах сильно меньших, чем это разумно при полноценном внедрении.

Сейчас переведу на физический...

Дело в том, что ITIL хорошо задаёт вектора развития, которые очень хорошо ложатся на телеком специфику.

Поэтому Вы абсолютно верно говорите, что отдельные элементы ITIL оправданы (а даже усилю - крайне полезны) даже на средних масштабах.

 

А теперь кратенько разберём TOGAF.

Вот статеечка http://www.ibm.com/developerworks/ru/library/r-temnenco/index.html

Смотрим рисунок 11

 

Мы видим, что на одном цикле проекта должно родиться 6 (шесть !) документов описывающих план работы.

Вы реально думаете, один человек, всего лишь стоящий между заказчиком и исполнителем должен всё это родить ?

А самое главное-то.

Где вектор-то, который задаёт TOGAF ? Документы рожать ?

Хотя опять же в для крупняка это абсолютно нормально.

 

Или вот ещё хорошая картинка - я бы её назвал мир во всём мире.

 

 

Ну да, для крупной IT компании наличие службы архитектора - необходимость.

Но Тимуру-то не нужно 8 архитекторов, причём за каждым из них нужно понимать стоит подразделение.

 

Поэтому TOGAF - это инструмент расшивки и обхода противоречий, чтоб избежать лишних рестартов циклов проектов из-за ошибок,

а ITIL - метод работы.

Поэтому ITIL применим на средних масштабах, да даже и на совсем малых, если много frontend работы,

а TOGAF ну вот как-то очень слабо.

 

Кстати TOGAF крайне похож на службы Главных Конструкторов советских КБ и НИИ.

Они функционировали похожим образом.

[Тимур]

Есть цена действия и есть цена бездействия.

 

Чисто интуитивно я бы попробовал найти готовую систему заточенную под обзвоны

[jab]

Чисто интуитивно я бы попробовал найти готовую систему заточенную под обзвоны

 

Вот тебе список, наслаждайся: http://www.voip-info.org/wiki/view/Predictive+dialer

[jab]

Как я понял, ему хочется прокачать скиллы лидеров групп, чтобы выделить более авторитетного товарища, который бы имел больше веса в принятии решений и могу бы взять на себя некоторые стратегические вопросы.

 

:-) И мы заранее знаем его имя, только вот авторитетный товарищ с большим весом почему-то против дополнительной нагрузки.

[kapa]

Сейчас перед нами стоит задача - поднять продающий коллцентр. Нужно обзовнить подключенных клиентов и им предложить допуслугу. OTT ТВ, если конкретно.

В рамках этой задачи, есть подзадача - организовать обзвон клиентской базы.

Я сейчас отвечу вопросом не на тот вопрос, что ты задавал :)

 

Тимур, тебе не кажется, что конкретно этот вопрос при твоих масштабах больше управленческий? Посадить обзвонщиков на сделку от продаж и дать им списки в руки. По результатом первых обзвонов отсечь плохих обзвонщиков, перераспределить нагрузку в пользу хороших, поощрить причастных....

 

Хотя, можно, конечно, и автоматизировать немного. Там же на копейки разработки? И тот бюджет, который мог бы радовать в это тяжёлое время разработчиков порадует кого-то ещё :)

 

Но мне кажется, что это просто неудачный пример у тебя. И смысл именно в том, что таких автоматизационных задач несколько десятков, и вот кто-то должен по ним собрать стоимости/сроки/эффекты и что-то запустить, а что-то притормозить?

Ну так и найди такого человека из тех, кто рвётся?

Мне кажется, что такой подход:

 

Вот поэтому и курсы. Я хочу отправить нескольких человек на обучение, в надежде что

- все проникнутся необходимостью культурного подхода

- появится кто-то кому будет интересно развиваться в этом направлении и он продвинется дальше остальных

- остальные не будут возражать, через чур уж горячо. Ну и при этом у всех будет некий единый язык в смысле управления проектами

не очень хорош тем, что эти несколько человек поедут в надежде оказаться тем самым человеком, все уже представят себя в его кресле, а в итоге большинство будет опущено на землю.

[NN----NN]

А зачем, если у Тимура анархическая структура управления? У него решения принимаются не командно-административно, а путем договоренностей и убеждений?

Мне показалось, что Тимуру несколько надоела прекрасная анархическая структура управления, точнее - мешает.

 

"Настоящих буйных мало, вот и нету вожаков" - значит нужна другая структура. Да, более формализованная, но при этом более эффективная.

Надо выделить лидера, дать ему полномочия и т.д.

[Тимур]

Сейчас перед нами стоит задача - поднять продающий коллцентр. Нужно обзовнить подключенных клиентов и им предложить допуслугу. OTT ТВ, если конкретно.

В рамках этой задачи, есть подзадача - организовать обзвон клиентской базы.

Я сейчас отвечу вопросом не на тот вопрос, что ты задавал :)

 

Тимур, тебе не кажется, что конкретно этот вопрос при твоих масштабах больше управленческий? Посадить обзвонщиков на сделку от продаж и дать им списки в руки. По результатом первых обзвонов отсечь плохих обзвонщиков, перераспределить нагрузку в пользу хороших, поощрить причастных....

 

Хотя, можно, конечно, и автоматизировать немного. Там же на копейки разработки?

 

 

Тут IMHO существенные экономические последствия. Когда ты рассчитываешь размер премии ты исходишь из какой-то статистической оценки продажи времени.

Автообзвон, а особенно многопоточный обзвон может дать кратный рост производительности

 

Разработка же тут копеечная. Но потом ведь захочется улучшений,интеграции, отчеты оценки, сервисы для обучения...

[Sonne]

А зачем, если у Тимура анархическая структура управления? У него решения принимаются не командно-административно, а путем договоренностей и убеждений?

Мне показалось, что Тимуру несколько надоела прекрасная анархическая структура управления, точнее - мешает.

 

"Настоящих буйных мало, вот и нету вожаков" - значит нужна другая структура. Да, более формализованная, но при этом более эффективная.

Надо выделить лидера, дать ему полномочия и т.д.

 

Так и будет структура. После того как нужный человек пойдет, выучится на курсах, станет настолько убедительным что остальные с ним согласятся.

Вы предлагаете проектировать функционал и под него искать людей. А Тимур держит людей и думает как развивать их возможности.

 

Я уже сказал, что не бывает правильных и неправильных вариантов. Если вспомнить, что бесконечное количество современных, бизнес-ориентированных компаний - продались, слились, исчезли, а Ринет живет и здравствует, то прямо не остаешься в сомнениях.

 

На самом деле вопрос был очень простой и логичный - посоветуйте где можно изучить управление проектами. Так вот почему бы буквально не ответить на вопрос?

 

А я отвечу - почему. Потому что вот с этим анархическим - "мы разгильдяи, очень плохо умеем" они может быть на голову выше всех советчиков вместе взятых, которые типа заранее знают наилучшее решение.

 

Вот начинается - формализуй структуру, найми опытного управленца = технического директора. Договоритесь сейчас для менеджера с MBA и консультантов Big4 (или 3 или сколько их там сейчас?). Да там наверно всего ФОТа менеджмента не хватит на зарплату этого золотого управленца, который придет структуру ломать. А главное зачем? Чтобы развалить системный договор компании, когда управленцы максимально поддерживают эффективность бизнеса, а владельцы - не ограничивают свободу коллектива и не продают компанию крупняку? (Это не какая то приватная информация, Тимур об этом и раньше писал).

 

Нет уж лучше на курсы, желательно самые лучшие. Мне кажется вот именно на этом тут экономить как раз не собирались.

[NN----NN]

Вот начинается - формализуй структуру, найми опытного управленца = технического директора. Договоритесь сейчас для менеджера с MBA и консультантов Big4 (или 3 или сколько их там сейчас?). Да там наверно всего ФОТа менеджмента не хватит на зарплату этого золотого управленца, который придет структуру ломать. А главное зачем? Чтобы развалить системный договор компании, когда управленцы максимально поддерживают эффективность бизнеса, а владельцы - не ограничивают свободу коллектива и не продают компанию крупняку? (Это не какая то приватная информация, Тимур об этом и раньше писал).

Это Ваша фантазия. Я не предлагал игнорировать курсы и не предлагал пригласить варяга.

 

Моё предложение - раз уж разговор зашёл о том, что надо как-то реорганизовать работу, как-то систематизировать, кого-то выдвинуть архитектора/менеджера проектов/руководителя кучи программистов, то почему бы заодно не пересмотреть внутренние организационные связи.

[kapa]

Тут IMHO существенные экономические последствия. Когда ты рассчитываешь размер премии ты исходишь из какой-то статистической оценки продажи времени.

Автообзвон, а особенно многопоточный обзвон может дать кратный рост производительности

Вот не вижу я тут потенциала для кратного роста. Простой список в экселе для упорядочивания по статусу при повторных проходках по списку - вот что даст максимальное ускорение.

Если деньги, вложенные в разработку, передать на премирование по результатам (т.е. не по количеству перебранных по базе телефонов, а по количеству привлечённых абонентов), то вот это максимально увеличит производительность. Причём именно ту, которую голой автоматизацией тебе поднять не удастся.

 

Разработка же тут копеечная. Но потом ведь захочется улучшений,интеграции, отчеты оценки, сервисы для обучения...

Потом кончатся абоненты :)

Или тебе есть ещё что на регулярной основе физикам предлагать, да так, чтоб они тебя в чёрный список не занесли? Делись ;)

[SergeiK]

На самом деле вопрос был очень простой и логичный - посоветуйте где можно изучить управление проектами. Так вот почему бы буквально не ответить на вопрос?

Потому что мы все - на русском форуме.

А на русском форуме простой ответ на простой вопрос - явление исключительное в своей редкости :).

 

Сейчас переведу на физический...

Спасибо за подробный ответ.

С вашего позволения, я немного поспорю, но позже.

[Тимур]

Если деньги, вложенные в разработку, передать на премирование по результатам (т.е. не по количеству перебранных по базе телефонов, а по количеству привлечённых абонентов), то вот это максимально увеличит производительность. Причём именно ту, которую голой автоматизацией тебе поднять не удастся.

 

Может быть да, а может быть нет. Пока не попробуешь - не узнаешь.

[SergeiK]

Давайте я вам, дорогие друзья, конкретный пример приведу. Ну просто чтобы разговор был предметней.

 

Сейчас перед нами стоит задача - поднять продающий коллцентр. Нужно обзовнить подключенных клиентов и им предложить допуслугу. OTT ТВ, если конкретно.

 

...

 

Как назвать человека, который может принять взвешенное решение по данному вопросу?

Это я еще не коснулся вопроса - а стоит ли делать свой коллцентр или проще и правильней отдать аутсорсерам, для которых это профильная деятельность

Показательный кейс.

 

Лично я вижу "смешалось в кучу кони, люди!".

 

1. Поднять продающий колл-центр.

Не ясно, его нет или что-то есть?

"Можно не морочится и раздать операторам выгрузки из базы." Операторы есть, а коллцентра нет? Или речь о том о ПО управления операторами?

 

2. Нужно обзвовнить подключенных клиентов и им предложить допуслугу.

Не ясно, это разовая задачи или такие задачи будут возникать регулярно. То есть решать надо частную конкретную задачу "обзвонить клиентов" или общую "пдонять продающий коллцентр"?

Если ты сделать решение для частной задачи, а потом растянуть на общую? Так можно, но надо оценить, насколько частная задачи типична, какие могут быть вариации и делать сразу решение под развитие. Как правило, это заметно усложняет работу

 

3. Есть ли оценка, сколько времени операторы, по схеме звонки по файлику потратят на эту задачу?

"Настоящий программист потратит неделю, чтоб автоматизировать и потом сделать за 5 минут задачу, которую иначе бы он решал два часа!".

 

4. Какие стоят сроки по частной задаче (когда-нибудь, вчера, до конца июня, к осени)?

"Любые сроки на внедрения решения увеличивай на порядок!". Если решения еще нет, планировать решение для использования к сроку Ч нельзя!

 

 

В общем, тут совместная работа руководителя - постановщика задачи, и архитектора, который поможет задачу формализовать, оценить возможные решения, исходя из имеющихся технических ресурсов и поставленных сроков и сформулированных целей.

Второй, вроде бы, похож на руководителя проекта, но архитектор должен владеть информацией, что и как в компании есть и работает, в то время как к ПМ-у таких требований нет, он работает в рамках выделенных ресурсов и поставленных задач.

[kapa]

У нас анархия. Куча систем, много заказчиков, много разработчиков. Центральной координации нет.

Есть ещё путь.

Назови анархию холакратией, раздай опционы, все кааак замотивируются бабки считать и не предлагать лишнее, а потом и о порядке разработки договорятся.

Заодно дополнительные бабки сможешь зарабатывать рассказывая за бабки другим на конференциях, как ты новый баззворд внедрил, и водя к себе экскурсии ;)

[Milon]

 

Показательный кейс.

 

Лично я вижу "смешалось в кучу кони, люди!".

Пример - отличный. он еще раз показал что Вы не понимаете проблемы TS.

как уже писали раньше в другой ветке - ему нужен второй Тимур: немножко админ, немножко экономист, немножко управленец и немножко лидер :) человек, который может просмотрит различные технические решения, просчитает их экономику, оценит сроки и перспективы развития, нарисует графики и презенташки и принесет решение на согласование главному вождю. такие люди долго растут из инженеров/админов/кодеров через project manager/team leader и редко попадаются по объявлению. и стать таким спецом нельзя окончив одни курсы. надо и PMBoK изучать, и с ITIL ознакомиться, и экономику и менеджмент подтянуть, так же обладая жизненным опытом и умея общаться с другими людьми. и при этому - технические скиллы не растерять со временем. а еще нужна харизма, хотя бы чуток. и желание руководством персонала заниматься.

в результате у меня рисуется образ технического менеджера среднего звена возрастом глубоко за 30, спокойно сидящем на своем стуле в крупной компании. :)

 

IMHO - нет таких курсов.

начинайте учить всему подряд, - с PMBoK и ITIL в первую очередь (по ним и курсов полно), с домашней работой в виде экономики и управления персоналом.а в ходе обучения станет видно - кому это интересно и на сколько.

нормальные инженеры, обычно, быстро сдуваются после первого же погружения в эти "44 метода в 5 областях знания" :)