[Тимур]

То есть скрам не имеет отношения к управления проектами? Аррригинально...

Таки да, не имеет. Что тебя удивляет? Скрам - это ярко выраженный процесс ;)

 

Ну... меня многое удивляет... звездное небо над головой... да много чего еще...

 

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

Scrum (от англ. scrum «толкучка») — методология управления проектами, активно применяющаяся при разработке информационных систем для гибкой разработки программного обеспечения.

 

Вот пруфлинк

 

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

 

Мы например выловили такой психологический баг. Персонал практически не воспринимает письменные инструкции. Ну то есть, человеку приходит письмо с описанием что нужно делать. А он это не воспринимает (делает все по другому).

 

Если же объяснить устно (но обязательно сопровождая письменным материалом), то восприятие идет гораздо правильнее.

Прекрасная иллюстрация. Сразу для нескольких моментов.

 

Вариант А. Написано нормально и достаточно. Большинству людей тупо не достает самодисциплины чтобы вникать, им проще самим себе объяснить что непонятно, и вообще - плохо воспринимается письменный текст. Поверь, что если бы у них по итогам был экзамен с ценой сдачи/не сдачи в один месячный оклад - то внезапно выяснилось бы, что прекрасно они умеют письменное воспринимать. В этом смысле "инструктор" играет ту же роль, что преподаватель на платных курсах. Никто не мешает тебе самому выучить любой язык - кроме лени. И ты платишь деньги за то, чтобы регулярно под руководством инструктора делать то, что ты прекрасно мог бы делать сам бесплатно ;)

 

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

 

Ключевой критерий отличия А от Б прост: если при "интерактивной" сессии дается тот же материал в той же структуре, что и в описаниях - это А. Если процесс и результат выглядит радикально по другому - Б.

 

Согласен с обоими мыслями

 

Просто я хочу сказать, что сущности в чем-то схожие но разные. И управляться с ними нужно по разному.

 

Не согласен, что по разному?

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

 

Ладно, Леша - ну я уже все лежу на ринге. Я уже понял, что ничего не понял. Засчитываем слив.

 

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

[Прохожий]

Я с тобой согласен. Запятая толстое НО.

Ты будешь смеяться, но я уже пятый год не могу закрыть эту вакансию :-)))

На этой позиции с разной степени неуспешности у меня успело провалиться четыре человека.

Это закономерно, потому что вытягиванию информации из людей и ее аналитической обработке нигде не учат кроме, разве что, очень специфичных заведений типа академии ГРУ ГШ.

 

Это ОЧЕНЬ трудоемко и ОЧЕНЬ специфично. Вот, например, чтобы действительно проработать одного источника надо пара часов интервью под диктофон, а после того от 6 до 10 раз прогнать через себя запись, причем, замечу, не в темпе интервью, а существенно медленнее. Итого где-то часов 20..30 на один источник. Ну это если ты действительно хочешь понять что как устроено ;) Это при том, что у тебя есть иллюзия, что ты на 100% понимаешь как что у тебя устроено )))))

 

Таких людей очень мало, а стоит их работа очень дорого.

 

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

Да ничего там не сложнее, не с того конца подходишь. Начнем с того, что здесь многие вещи и не нужно делегировать ;) Т.е. ищешь ты там, где светлее, а не там, где потерял :)

 

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

Вычленять - полезно, плодить - вредно )))))

 

В случае же с омега проектами и X-проектами ситуация принципиально иная.

Конечно иная. Потому что это вообще не проекты.

 

От проблемы "неопредеделенность в целях проектов" есть производные проблемы

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

 

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

- роадмап (последовательность и состав эпик тасков, кто на кого и как влияет)

- ответственные по таскам

- актуальное состояние (какие эпики взяты и когда (не просто таскдан, но и таскдан в 1м квартале))

- план (когда собираемся взять таск)

Йоперныйтеатр!

Тимур, роадмап - это ну вот точно не последовательность тасков, тебя обманули! И на этом все твои построения наворачиваются лицом о твердую реальность ;)

 

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

 

Второе. У меня сложилось ощущение, что ты веришь в Нерушимость Планов. Это фигня. Не бывает планов, которые точно исполняются. В принципе не бывает. Поэтому всегда есть:

- вехи проекта = важные промежуточные результаты

- базовый план = как хотели на старте, включая вехи, кстати

- оперативный план = как СЕГОДНЯ мы видим будущее исходя из того состояния дел и информации, которая есть у нас сегодня. Тоже, между прочим, включая вехи.

 

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

 

Впрочем, работа с целями - оно в той же мере искусство, в какой им является управление проектами если не брать в расчет существование PMI и множества других методик ;) Просто для нее работают иные механизмы, правила, методы и т.д., а ты пытаешься засунуть это все в прокрустово ложе проектного управления. Ложе трещит и обрубает голову, как полагается. "Не надо так!" (с)

 

Проблема в том, что работа с целями - это работа в чистом виде аналитическая! Она не может быть заменена ни вычислениями, ни организацией, ни методологией, а любая методология относительно этой работы носит вспомогательный характер и максимум как-то форматирует процесс анализа и вид результата. Но не предопределяет его. Если в случае PMI или BPM ты в общем имеешь представление о том что будет как и чем кончится, здесь этого представления в принципе нет. И что самое главное - это работа в принципе не управленческая. Ее нельзя делегировать за исключением каких-то сугубо технических аспектов, т.е. ты можешь устроить со всем своим топ-персоналом и владельцами "стратегическую сессию", пригласить на нее хорошего модератора (что, кстати, резко увеличивает вероятность ее продуктивности!), но при этом результат зависит все же от вас, а не от модератора. Он катализатор, но не реагент. Ускоряет реакцию, а не создает ее. Поэтому сама мысль, что можно нанять какого ни будь "директора по развитию" и он придумает вам стратегию - бредова. ИМХО.

 

Не помню, ты по-буржуйски читаешь? А то тебе могло бы быть интересно вот это: http://people.dsv.su.se/~pajo/busital2008/paper2.pdf Там как раз про цели. Кстати, там же ссылка на источник по уровням управления. Hofer C., & Schendel D., Strategic Management: A New View of Business Policy and Planning. Toronto, Canada: Little, Brown and Company (Inc.), 1979.

 

According to Hoffer and colleagues [14] organizational goals are categorized into three distinct levels namely, the strategic, tactical, and operational levels. Strategic level goals are broadly defined to support the mission statement and are set by and for top management of the organization. Tactical level goals support the strategic level goals and are set by and for middle managers. Goals at this level focus on how to operationalize the strategic goals and, indicate the levels of achievement necessary in the departments. Operational goals are determined at the lowest level of the organization and are set by and for low-level managers to support the tactical goals. At each level, the goals are defined with different degrees of abstraction, inherit varying complexities, and serve different purposes. For example, at the strategic level, goals are abstractly defined with the aim of supporting the mission and vision statements. At this level, there are no clear directions of how the goals will be realized. At the tactical level, department heads define goals for each department relative to the strategic goals, and while the directions of achievement may be clearer, the goal definitions are sometimes restrictive to the department. At the operational level, goals are determined for realizing the outcome of specific processes. These goals may be realized individually or by stakeholders working on the same process.

 

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

 

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

 

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

 

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

 

Ибо компьютер думать не умеет. Увы.

[Прохожий]

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

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

 

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

 

Ладно, Леша - ну я уже все лежу на ринге. Я уже понял, что ничего не понял. Засчитываем слив.

 

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

А смысл? ;) Так вот получилось, что выше я по уровням уже все разрисовал в первом приближении ;)

[LionSprings]

Кови дядька толковый

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

скрам не имеет отношения к управления проектами? Аррригинально...

Ну, наверное сказать, что "не имеет отношения" нельзя, но с этой точки зрения солнце и пиво тоже имеют отношение к управлению проектами.

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

Интересно, сколько времени и нервов это заняло?

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

[karpa13a]

Это закономерно, потому что вытягиванию информации из людей и ее аналитической обработке нигде не учат кроме, разве что, очень специфичных заведений типа академии ГРУ ГШ.

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

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

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

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

персонал канеш не сильно будет в восторге) но это уже другой вопрос)

[Sergey Gilfanov]

Это закономерно, потому что вытягиванию информации из людей и ее аналитической обработке нигде не учат кроме, разве что, очень специфичных заведений типа академии ГРУ ГШ.

А куда делись всякие аналитики из разработчиков ПО? Их, по идее, как раз учат вытягивать из клиента 'чего ему на самом деле надо'?

 

Это ОЧЕНЬ трудоемко и ОЧЕНЬ специфично. Вот, например, чтобы действительно проработать одного источника надо пара часов интервью под диктофон, а после того от 6 до 10 раз прогнать через себя запись, причем, замечу, не в темпе интервью, а существенно медленнее. Итого где-то часов 20..30 на один источник. Ну это если ты действительно хочешь понять что как устроено ;) Это при том, что у тебя есть иллюзия, что ты на 100% понимаешь как что у тебя устроено )))))

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

[Sergey Gilfanov]

Не помню, ты по-буржуйски читаешь? А то тебе могло бы быть интересно вот это: http://people.dsv.su.se/~pajo/busital2008/paper2.pdf.

Полез по URL-у повыше. Ну явно же домашняя страница аналитика по ПО.

[Прохожий]

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

Весьма интересно. Надо не забыть.

 

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

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

Кстати, да, следователи - это как раз специально обученные люди. Если учились хорошо, конечно.

 

А куда делись всякие аналитики из разработчиков ПО? Их, по идее, как раз учат вытягивать из клиента 'чего ему на самом деле надо'?

В общем-то да. Но сейчас аналитики по ПО больше отползли в сторону всяких там УМЛ и прочих формальных моделей, от которых можно переходить почти линейно к требованиям ИС

 

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

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

 

Полез по URL-у повыше. Ну явно же домашняя страница аналитика по ПО.

Лучше бы ты на выходные данные документов смотрел, больше толку бы было ;) Если бы оно на гей-сайте было опубликовано, что бы поменялось в смысловой нагрузке?

[Sergey Gilfanov]

А куда делись всякие аналитики из разработчиков ПО? Их, по идее, как раз учат вытягивать из клиента 'чего ему на самом деле надо'?

В общем-то да. Но сейчас аналитики по ПО больше отползли в сторону всяких там УМЛ и прочих формальных моделей, от которых можно переходить почти линейно к требованиям ИС

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

[Тимур]

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

Вообще-то это обязанности владельцев фирмы и высшего руководство. Кому ты их собрался делегировать?

 

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

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

К таком состоянию нельзя прийти декретно. Это вопрос развития корпоративной культуры.

 

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

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

 

Я с тобой согласен. Запятая толстое НО.

Ты будешь смеяться, но я уже пятый год не могу закрыть эту вакансию :-)))

На этой позиции с разной степени неуспешности у меня успело провалиться четыре человека.

Это закономерно, потому что вытягиванию информации из людей и ее аналитической обработке нигде не учат кроме, разве что, очень специфичных заведений типа академии ГРУ ГШ.

 

Это ОЧЕНЬ трудоемко и ОЧЕНЬ специфично. Вот, например, чтобы действительно проработать одного источника надо пара часов интервью под диктофон, а после того от 6 до 10 раз прогнать через себя запись, причем, замечу, не в темпе интервью, а существенно медленнее. Итого где-то часов 20..30 на один источник. Ну это если ты действительно хочешь понять что как устроено ;) Это при том, что у тебя есть иллюзия, что ты на 100% понимаешь как что у тебя устроено )))))

 

Таких людей очень мало, а стоит их работа очень дорого.

 

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

 

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

 

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

[Тимур]

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

 

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

 

Ладно, Леша - ну я уже все лежу на ринге. Я уже понял, что ничего не понял. Засчитываем слив.

 

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

А смысл? ;) Так вот получилось, что выше я по уровням уже все разрисовал в первом приближении ;)

 

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

 

Подчеркну - не только я один путаю проекты, процессы, программы, продукты и прочие производные от проактивных примочек к производственным процессам :-)

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

 

Но конечно, смысл просвещать человечество не много ;-)

 

Если тебе не до того - то просто значит нам такая судьба не знать правду о проектах. :-)))

[Прохожий]

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

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

К таком состоянию нельзя прийти декретно. Это вопрос развития корпоративной культуры.

Тимур, надо четко отделять вещи, которые можно превратить в институты от вещей, которые нельзя ;) Разработка стратегии не может быть инсту... инсти... ну в общем, превращена в бизнес-процесс. Потому что стратегия и видение - всегда удел немногих. Можно проводить всякие коллективные мероприятия, мозгоштурмить, определять число Пи голосованием, ужраться в полную сосиску всем топ-менеджментом (этим чаще всего заканчиваются выездные стратегические сессии!), но формулировать и принимать решения придется все равно кому-то одному. Здесь я имею ввиду очень конкретный блок активностей, имеющих целью получение хотя бы сколько ни будь сформулированной стратегии для бизнеса. Это фактически всегда штучная работа :)

 

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

 

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

 

Резюмируя: "Институализация развития" - это слишком обще для того, чтобы даже обсуждать саму ее возможность. Потому что "развитие" - не инициализированная переменная. У нее нет значения, одинакового для нас обоих. А вот вполне понятные компоненты контура ИЗМЕНЕНИЙ в бизнесе не только могут, но и должны быть инс... инститр... Ну ты понял!

 

Тут ведь важна сама способность взбаламучивать воду. А разгребать последствия дурных шагов менеджмент у нас умеет неплохо :-))

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

 

Лет через десять будешь как Азидес. И будешь продавать провайдерам софт, выдающий сообщения типа "Астрологи объявили неделю Гоблинов. Монтажники получают +30% к зарплате."

 

))))))))

 

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

Ну так уж и невежества ;)

 

Могу только еще раз сослаться на себя же: https://pavlyuts.ru/posts/69

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

 

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

 

Если ты имеешь цель получить конкретный результат затратив на это вполне конкретное количество времени и ресурсов - это проект. Ключевое здесь - ты понимаешь результат. И понимаешь как ты его будешь достигать.

 

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

 

Собственно, это и все. Что здесь не понятно? ))))))

[Тимур]

Могу только еще раз сослаться на себя же: https://pavlyuts.ru/posts/69

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

 

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

 

Если ты имеешь цель получить конкретный результат затратив на это вполне конкретное количество времени и ресурсов - это проект. Ключевое здесь - ты понимаешь результат. И понимаешь как ты его будешь достигать.

 

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

 

Собственно, это и все. Что здесь не понятно? ))))))

 

Кое-что мне понятно, а кое-что непонятно.

Понятно, что например поточная разработка сайтов укладывается в оба определения. Ситуацию можно описывать и как процесс и как проект. А ситуации с существенной исследовательской составляющей не ложатся ни туда и ни туда.

Вот такая классификация. Тогда вопрос - а в чем от нее польза?

 

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

Но что именно плохо? Какие отрицательные последствия происходят от того, что я не классифицирую ситуации?

[Kirya]

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

После этого этим же стали у вас заниматься и ваши сотрудники.

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

в каком случае напильник держать нужно параллельно детали, в каком перпендикулярно, и вести в ней учёт деталей.

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

 

А тут уже подход нужно менять.

Я тебе тут пытался тебе объяснить, что нужно вначале заняться мотивацией, но ты меня не слышишь.

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

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

 

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

И тоже правильно.

И даже методики предлагает.

 

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

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

Это не только трудоёмко, но и вредно.

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

[Тимур]

Я тебе тут пытался тебе объяснить, что нужно вначале заняться мотивацией, но ты меня не слышишь.

 

Я там выше написал несколько здоровенных кусков про мотивацию.

 

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

[Kirya]

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

Да и вы не диверсифицированная фирма, которая имела бы долгий опыт работы на нескольких рынках одновременно.

Люди просто не переварят.

Т.е указывать нужно пока что только стратегические цели.

А ты посчитай, сколько ты уже напечатал...

[Тимур]

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

 

Так-то оно так.

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

[Sergey Gilfanov]

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

(кусь)

А ты посчитай, сколько ты уже напечатал...

"За нас все должны делать роботы" - вполне себе цель, собственно.

[Тимур]

"За нас все должны делать роботы" - вполне себе цель, собственно.

 

Если мы говорим о стратегическом уровне, то это не моя цель

 

Моя цель внедрить конструктивные коммуникации

[Прохожий]

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

Тим, 98% сотрудников стратегический уровень нахер не вперся для того, чтобы делать свою работу за зарплату. Ты там чего, политическую партию строишь или партизанский отряд? Или таки бизнес? Сколько там у вас народу, человек 300? Ну вот значит какое-то отношение к стратегии имеют человек пять максимум, остальным она тупо не нужна для эффективной работы, и даже мешает. До них она должна доноситься в виде внутреннего пиара "мы к 20 году захватим Галактику, и вообще мы крутые, потому что мы БАНДА!!!" Ну и Тимур, читающий рэп и делающий плов по праздникам. ВСЕ! ***й никому не вперлась ни реальная стратегия, ни реальные вызовы стратегического уровня в том виде, в котором их реально надо осознавать.

 

НЕ НАДО сотрудникам "в целом понимать что происходит". Понимание, где место монтажника в цепочке людей, делающих клиента счастливым - можно засунуть в голову за 10 минут.

 

В общем, я твоих рефлексий тупо не понимаю. Что ты пытаешься сделать? Построить новгородское вече? Разделить со всем коллективом ответственность топ-менеджера за судьбу бизнеса, и, как следствие - их собственную? В этом нет смысла, на твоих размерах это уже не работает. ИМХО.

 

Моя цель внедрить конструктивные коммуникации

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

Это ложная цель. Она может быть только очень промежуточной и вторичной целью. А вот относительно чего? ;)

[jab]

Ты там чего, политическую партию строишь или партизанский отряд?

 

По факту - махновскую банду. ;-)

[Тимур]

Моя цель внедрить конструктивные коммуникации

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

Это ложная цель. Она может быть только очень промежуточной и вторичной целью. А вот относительно чего? ;)

 

Вот всегда так. Мне очень тяжело формулировать правильно цель. Я все время говорю, что нужно делать, не акцентируя на "зачем это сделать"

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

 

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

 

Ты там чего, политическую партию строишь или партизанский отряд?

 

По факту - махновскую банду. ;-)

 

Я вроде с самого начал сказал, что тут собрались анархисты?

[jab]

Я вроде с самого начал сказал, что тут собрались анархисты?

 

Очевидно, что анархия, дисциплина, эффективность и мотивация - понятия ортогональные. :-)

[Тимур]

Я вроде с самого начал сказал, что тут собрались анархисты?

 

Очевидно, что анархия, дисциплина, эффективность и мотивация - понятия ортогональные. :-)

 

Ортогональные или противоречивые? ;-)

[Прохожий]

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

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