Отличие вуза и ПТУ вовсе не в том, что в первом фундаментальные знания, а во втором — прикладные. Дураку понятно, что некоторое количество общих теоретических знаний есть и в ПТУ, и даже в школе, в то же время прикладные дисциплины изучаются во всех институтах, потому что без них специалист не будет подготовлен.
Разница именно в подходе. ПТУ ориентируется на приобретение человеком навыков работы в конкретной производственной роли. Вуз ориентируется на приобретение человеком более широкого спектра знаний, частным случаем которых будет его специальность, для которой он получит нужные навыки.
Вопреки распространённому мнению, вуз — это не для тех, кому нужна наука. Наука начинается только после диплома, в аспирантуре. Концептуально, отличие специалиста с высшим образованием от средне-специального в более системном видении всего процесса, в который включена его деятельность. Этим отличается инженер от техника, доктор до санитара, экономист от бухгалтера и так далее.
В индустриальную эпоху было проще — большинство профессий были либо очевидно «высшими», требующими большого количества знаний, либо очевидно «специальными» — требующими навыков ручного труда. Программист — это, пожалуй, первая массовая профессия, которая одинаково востребована и в «низкоквалифицированном» виде, и в «высококвалифицированном». Отсюда и постоянные споры о нужности или ненужности высшего образования.
Чтобы успешно начать работать — нет, оно не нужно. Чтобы стать по-настоящему хорошим специалистом — крайне желательно.
Мне кажется (хоть мой английский и не настолько хорош, чтобы утверждать это наверняка), что лицензия Chrome не разрешает использование его как части собственного программного продукта (п. 9.2. EULA www.google.com/intl/en_sg/chrome/privacy/eula_text.html, а также в п.3 дополнительной части, касающейся прав Adobe в этом же документе).
Использование бесплатного пользовательского продукта могут привести и к неудобствам, например, в виде внезапных изменений после обновления браузера, из-за которых немного изменится рендеринг или что-то ещё. Браузер для тестирования в проекте вы обновляете до последней версии и это нормально, а вот инструмент для генерации pdf нет нужды трогать без необходимости, пока pdf нормально генерируется.
Ну вот вы нарисовали треугольник, и говорите о том, что будет плохо, если какая-то вершина начнёт «доминировать». А что это значит в контексте Процессов, Целей? Если я много внимания уделяю процессам, то может они наоборот — отлаженные и адаптированные, и позволяют избегать бюрократии? То же и с целями. Много внимания к вершине — что это вообще значит?
Вот вы вводите потоки. Чем это отличается, грубо говоря, от обычной схемы «процесс управления — процесс производства — процесс анализа данных с внесением изменений»?
Как взаимодействуют ваши концепции поток и треугольника? Что такое Пульс?
Вот вы знаете, когда человек действительно хочет донести новую идею, он старается объяснить её известными словами.
Вы же просто вводите огромное количество новых слов, не останавливаясь подробно на их значении. Даже если всё это имеет какой-то интересный внутренний смысл, то к нему очень сложно подойти, нужно затратить очень много усилий.
Я не готов сходу подготовить какой-нибудь целостный реферат, но вот я посмотрел, навскидку, в википедии в статье «Менеджмент» более-менее здраво рассмотрена эволюция этой области знаний, в ней упоминаются нужные слова, можете ознакомиться.
Как у инженера, я думаю, у вас не возникнет вопросов в «научности» подходов к управлению, которые применяются в технике, которые в свою очередь являются смежными к теории информации и какой-нибудь кибернетике. Эти же методы управления, методы принятия решений и прочее давно рассмотрены и в более общих понятиях (выше которых начинается уже чистая философия, которая конечно наукой не является), и по возможности применяются там, где необходимо создать систему, состоящую не только из автоматов, но и из людей. Многие подходы к управлению системой из людей остаются теми же — системный подход, системный анализ, процессный подход. К менеджменту, конечно, добавляется область знаний, связанных с психологией и поведением людей, к которой можно относиться довольно скептически, но она является далеко не единственным его содержанием.
Все эти современные «теории управления» можно попробовать применить на практике и получить конкретные результаты. На основании множества экспериментов и делаются выводы о результативности и эффективности различных подходов, так что нынешние громоздкие обобщённые стандарты управления, типа ISO 9001 — это и есть зримое достижение менеджмента, как прикладной науки. Именно эти инновации, как считается, обеспечили «японское экономическое чудо» во второй половине двадцатого века и кое-какие чудеса помельче. Научным подходом к управлению занимались и в СССР, а тогда мало кого можно было заподозрить в недостаточно материалистичном взгляде на вещи.
В общем, теория и научный подход в управлении определённо есть, и знание теории может помочь достичь более высокой производительности труда и прийти к организации деятельности быстрее, не набивая шишек собственным лбом. Проблема в том, что многим кажется, что управление людьми — это нечто интуитивное, решаемое простым командным способом или лидерскими качествами (а это применимо далеко не везде), и изучением основ пренебрегают. Также в нашей стране традиционно считалось, что управление — это административная работа, и специальность менеджера — это пристанище для тех, кто оказался неспособен к технике. По катастрофически низкой производительности труда, проблема с которой тянется ещё со времен позднего СССР, мы можем видеть, что это не очень правильный подход к образованию.
В предыдущем комментарии ответил только на постскриптум, потому что не было времени.
Давайте считать (полагаю, что это не противоречит вашему видению) что методология — это организационная система, которая позволяет команде делать продукт результативно и с нужной степенью эффективности.
Вы говорите: методологии дорогие. Большинство методологий ничего не стоят. Консультанты берут деньги за их внедрение или консультации по ним. Если вы имеете голову на плечах, здравый смысл, и желание работать организованно, то можете пользоваться любой методологией бесплатно.
Вы говорите: методологии не решают именно ваших задач. Это чистая правда.
Методологии можно условно разделить на две больших группы. Первая группа — это нечто, выросшее из «взрослого» менеджмента, исходящие из теоретических предпосылок о проектном управлении. Это и управление напрямую по PMBOK или RUP-методологии, попытки сертифицироваться на соответствие ГОСТ Р 12207/9001 и прочему — всё это действительно тяжело и совершенно не подходит для того, чтобы взять и начать пользоваться.
Есть вторая группа методологий, и к ним относятся большая часть agile-историй, которые появились в ответ на тяжесть корпоративных управленческих систем. Это всякие Scrum, XP, TDD, тысячи их. Проблема таких практик в том, что они зародились в девелоперской среде, снизу, как наблюдение за удачно сложившимся конкретным процессом в каком-то конкретном проекте. Участники процесса попытались обобщить свои практики и составить из них методологию. Плюсом здесь является интуитивная понятность, лёгкость, и зачастую возможность непосредственного внедрения в дело. Как раз бездумное следование любой подобной методике и может привести к провалу, поскольку, как вы верно заметили, они наверняка не до конца отвечают именно вашим задачам.
Единственный правильный способ создания собственной, идеально соответствующей проекту методологии — это наличие в команде человека, способного деконструировать известные практики и создать на их основе то, что нужно. Потому что, несмотря на то, что все проекты уникальны по определению, проектная работа действительно разбивается на одни и те же процессы, хоть и меняется их интенсивность, состав ролей, потоки обратной связи и состав данных.
CMMI как раз является стандартом, которым можно пользоваться как подсказкой. Если вы чувствуете, что у вас постоянно возникают какие-то системные проблемы в работе, вы можете вдумчиво почитать про второй уровень зрелости и понять, что вам не хватает порядка в процессе деплоя или в структурировании потока требований от заказчика — и точечно принять меры по этому поводу. Никто не требует внедрять конкретных практик, софта или проходить сертификаций.
Другое дело, что CMMI написан весьма теоретически, для людей, изучавших управление. Мне кажется, и я в своё время пытался подойти к написанию работы на этот счёт, что такое усложнение совершенно не обязательно.
Именно поэтому я заинтересовался вашей статьёй. Конструктор методологии — это именно то, что нужно отрасли. Но для этого он должен быть легко применим, им надо иметь возможность воспользоваться, трансформировать с помощью него свои процессы, когда это нужно, и так далее. Если у кого-то получится сделать это, не привлекая тяжеловесной менеджерской теории процессного подхода и tqm, то это будет очень круто.
Современные подходы к управлению — это вполне инженерная наука, я это вам говорю как человек, у которого в дипломе написано «инженер-менеджер».
И для меня странно, что инженер не хочет подойти к организации своего труда с инженерным подходом, методически.
Я имел в виду, что в заголовке была заявлена методология. А методология видится мне чем-то более системным, упорядоченным, чётко выстроенным вокруг центральной идеи, чем эта статья. Здесь много разных интересных и полезных практических советов на разных этапах, но множество полезных практик не формируют методологию.
Говоря иначе, я думаю, что методология — это рецепт, которым можно воспользоваться. Здесь же, по сути, всё сводится к идее: «смело выбирайте наиболее подходящий вам практический подход для каждой стадии», и на примерах показаны некоторые частные решения. Для того, чтобы последовать этому совету и получить результат, нужен инженерный и управленческий опыт, нужно ориентироваться в мире практик и теорий, понимать чем они отличаются, какие имеют плюсы и минусы. Но человек, который всё это знает, и сам понимает, что каждая практика или метод — это лишь инструмент настройщика рабочего процесса.
Существует такой здоровенный и скучный стандарт CMMI, который во многом решает задачу, которая заявлена в статье. Он рассматривает процесс создания ПО и делит его на уровни зрелости — от полностью хаотичного до безумно организованного. В нём не описаны практики, конкретные советы и способы написания кода, есть только целевые задачи. Например, на втором уровне нужно обеспечить управление требованиями и управление конфигурацией — что-то в этом духе. (У них предполагается, что организация будет последовательно развивать свою систему, двигаясь к организации, но это не обязательно принимать как руководство к действию, можно просто понимать, чего тебе не хватает на очевидно твоём уровне).
Отличие этого стандарта от данной статьи в том, что им действительно можно воспользоваться как конструктором. Взять нужный уровень, посмотреть, какие процессы на нём должны быть в твоей системе управления разработкой, и под каждый процесс что-то внедрить. Этот набор целевых задач для каждого уровня согласован с существующими теоретическими достижениями в управлении, с процессными подходами и так далее, то есть, он хорошо работает как подсказка для конструирования.
Вот чего-то такого мне не хватило в статье, хотя в целом мне не с чем там принципиально поспорить, все практические советы написаны вполне по делу.
Диагностическая карта сегодня нужна не государству, а страховой компании, которая продаёт вам ОСАГО. Страховой нужно закрыть свои риски, для этого её обязали смотреть на техническое состояние автомобиля.
Практика показала, что страховым компаниям на этот риск абсолютно наплевать, и карту они готовы подделать, лишь бы ОСАГО купили у них.
При этом, не забывайте, в случае аварии они могут сказать вам, что вы не проходили осмотр, ваша карта подделана и никакой выплаты вы не получите (и страховая снова в шоколаде).
Так что дело ваше, я бы на вашем месте осмотр проходил, тем более что стоит это недорого и отнимает не больше часа времени, если с машиной всё в порядке.
Лес с палаткой — это другое, там нужно непрерывно заниматься обеспечением жизненных потребностей. А поездка — это поездка, делать ничего не надо, только смотреть на перемещение.
Хорошее путешествие совершается ещё и в голове. Мне кажется, что поездка по транссибу и автопробег между побережьями США — это маршруты, которые привлекают людей именно самим фактом пересечения пространства, то есть они интересны не как траектория между интересными местами. Наоборот, в какой-то момент как раз тот факт, что за окном ничего не меняется часами, создаёт нужное состояние, после которого путешественники пишут, что стали другими людьми.
Аналогия с машинами неуместная. Я же говорю, многие важнейшие вещи в ВК просто удобнее, и так продолжается уже много лет. Я каждый день пользуюсь и той и другой соцсетью, и серьёзный плюс у фейсбука только один — глобальная аудитория (и его ничем не перебить).
Насчёт легальности. Видно, что ВК много работает в этом отношении, но стараясь усидеть на двух стульях. Значительная часть музыки закрывается от бесплатного доступа, но это касается в основном всякой новой, коммерчески актуальной продукции, по которой могут возникнуть претензии.
У ВК есть подписка на музыку, которая снимает все ограничения, и по сути это стриминговый сервис с легализацией контента, который вы слушаете.
Вот по поводу видео ничего сказать не могу.
Что такого есть в фейсбуке прогрессивного, чего нет вконтакте? Крутая фича только с автоматическим распознаванием друзей на фотках, это реально эффектно.
Работа с фото, мессенджер, интерфейс для музыки (там, кстати, наладилось с легальностью), понятная механика работы пабликов, более понятный принцип формирования ленты — всё это в вк гораздо удобнее.
Тем не менее, ранний ВК был на порядок удобнее в плане работы с фоточками (и до сих пор у ФБ какой-то дикий ужас в этом отношении), имел и другие фичи, ещё у него была «стена», короче, самобытности хватало.
Разница именно в подходе. ПТУ ориентируется на приобретение человеком навыков работы в конкретной производственной роли. Вуз ориентируется на приобретение человеком более широкого спектра знаний, частным случаем которых будет его специальность, для которой он получит нужные навыки.
Вопреки распространённому мнению, вуз — это не для тех, кому нужна наука. Наука начинается только после диплома, в аспирантуре. Концептуально, отличие специалиста с высшим образованием от средне-специального в более системном видении всего процесса, в который включена его деятельность. Этим отличается инженер от техника, доктор до санитара, экономист от бухгалтера и так далее.
В индустриальную эпоху было проще — большинство профессий были либо очевидно «высшими», требующими большого количества знаний, либо очевидно «специальными» — требующими навыков ручного труда. Программист — это, пожалуй, первая массовая профессия, которая одинаково востребована и в «низкоквалифицированном» виде, и в «высококвалифицированном». Отсюда и постоянные споры о нужности или ненужности высшего образования.
Чтобы успешно начать работать — нет, оно не нужно. Чтобы стать по-настоящему хорошим специалистом — крайне желательно.
Использование бесплатного пользовательского продукта могут привести и к неудобствам, например, в виде внезапных изменений после обновления браузера, из-за которых немного изменится рендеринг или что-то ещё. Браузер для тестирования в проекте вы обновляете до последней версии и это нормально, а вот инструмент для генерации pdf нет нужды трогать без необходимости, пока pdf нормально генерируется.
В общем, есть пара принципиальных проблем.
Вот вы вводите потоки. Чем это отличается, грубо говоря, от обычной схемы «процесс управления — процесс производства — процесс анализа данных с внесением изменений»?
Как взаимодействуют ваши концепции поток и треугольника? Что такое Пульс?
Вы же просто вводите огромное количество новых слов, не останавливаясь подробно на их значении. Даже если всё это имеет какой-то интересный внутренний смысл, то к нему очень сложно подойти, нужно затратить очень много усилий.
Как у инженера, я думаю, у вас не возникнет вопросов в «научности» подходов к управлению, которые применяются в технике, которые в свою очередь являются смежными к теории информации и какой-нибудь кибернетике. Эти же методы управления, методы принятия решений и прочее давно рассмотрены и в более общих понятиях (выше которых начинается уже чистая философия, которая конечно наукой не является), и по возможности применяются там, где необходимо создать систему, состоящую не только из автоматов, но и из людей. Многие подходы к управлению системой из людей остаются теми же — системный подход, системный анализ, процессный подход. К менеджменту, конечно, добавляется область знаний, связанных с психологией и поведением людей, к которой можно относиться довольно скептически, но она является далеко не единственным его содержанием.
Все эти современные «теории управления» можно попробовать применить на практике и получить конкретные результаты. На основании множества экспериментов и делаются выводы о результативности и эффективности различных подходов, так что нынешние громоздкие обобщённые стандарты управления, типа ISO 9001 — это и есть зримое достижение менеджмента, как прикладной науки. Именно эти инновации, как считается, обеспечили «японское экономическое чудо» во второй половине двадцатого века и кое-какие чудеса помельче. Научным подходом к управлению занимались и в СССР, а тогда мало кого можно было заподозрить в недостаточно материалистичном взгляде на вещи.
В общем, теория и научный подход в управлении определённо есть, и знание теории может помочь достичь более высокой производительности труда и прийти к организации деятельности быстрее, не набивая шишек собственным лбом. Проблема в том, что многим кажется, что управление людьми — это нечто интуитивное, решаемое простым командным способом или лидерскими качествами (а это применимо далеко не везде), и изучением основ пренебрегают. Также в нашей стране традиционно считалось, что управление — это административная работа, и специальность менеджера — это пристанище для тех, кто оказался неспособен к технике. По катастрофически низкой производительности труда, проблема с которой тянется ещё со времен позднего СССР, мы можем видеть, что это не очень правильный подход к образованию.
Давайте считать (полагаю, что это не противоречит вашему видению) что методология — это организационная система, которая позволяет команде делать продукт результативно и с нужной степенью эффективности.
Вы говорите: методологии дорогие. Большинство методологий ничего не стоят. Консультанты берут деньги за их внедрение или консультации по ним. Если вы имеете голову на плечах, здравый смысл, и желание работать организованно, то можете пользоваться любой методологией бесплатно.
Вы говорите: методологии не решают именно ваших задач. Это чистая правда.
Методологии можно условно разделить на две больших группы. Первая группа — это нечто, выросшее из «взрослого» менеджмента, исходящие из теоретических предпосылок о проектном управлении. Это и управление напрямую по PMBOK или RUP-методологии, попытки сертифицироваться на соответствие ГОСТ Р 12207/9001 и прочему — всё это действительно тяжело и совершенно не подходит для того, чтобы взять и начать пользоваться.
Есть вторая группа методологий, и к ним относятся большая часть agile-историй, которые появились в ответ на тяжесть корпоративных управленческих систем. Это всякие Scrum, XP, TDD, тысячи их. Проблема таких практик в том, что они зародились в девелоперской среде, снизу, как наблюдение за удачно сложившимся конкретным процессом в каком-то конкретном проекте. Участники процесса попытались обобщить свои практики и составить из них методологию. Плюсом здесь является интуитивная понятность, лёгкость, и зачастую возможность непосредственного внедрения в дело. Как раз бездумное следование любой подобной методике и может привести к провалу, поскольку, как вы верно заметили, они наверняка не до конца отвечают именно вашим задачам.
Единственный правильный способ создания собственной, идеально соответствующей проекту методологии — это наличие в команде человека, способного деконструировать известные практики и создать на их основе то, что нужно. Потому что, несмотря на то, что все проекты уникальны по определению, проектная работа действительно разбивается на одни и те же процессы, хоть и меняется их интенсивность, состав ролей, потоки обратной связи и состав данных.
CMMI как раз является стандартом, которым можно пользоваться как подсказкой. Если вы чувствуете, что у вас постоянно возникают какие-то системные проблемы в работе, вы можете вдумчиво почитать про второй уровень зрелости и понять, что вам не хватает порядка в процессе деплоя или в структурировании потока требований от заказчика — и точечно принять меры по этому поводу. Никто не требует внедрять конкретных практик, софта или проходить сертификаций.
Другое дело, что CMMI написан весьма теоретически, для людей, изучавших управление. Мне кажется, и я в своё время пытался подойти к написанию работы на этот счёт, что такое усложнение совершенно не обязательно.
Именно поэтому я заинтересовался вашей статьёй. Конструктор методологии — это именно то, что нужно отрасли. Но для этого он должен быть легко применим, им надо иметь возможность воспользоваться, трансформировать с помощью него свои процессы, когда это нужно, и так далее. Если у кого-то получится сделать это, не привлекая тяжеловесной менеджерской теории процессного подхода и tqm, то это будет очень круто.
И для меня странно, что инженер не хочет подойти к организации своего труда с инженерным подходом, методически.
Говоря иначе, я думаю, что методология — это рецепт, которым можно воспользоваться. Здесь же, по сути, всё сводится к идее: «смело выбирайте наиболее подходящий вам практический подход для каждой стадии», и на примерах показаны некоторые частные решения. Для того, чтобы последовать этому совету и получить результат, нужен инженерный и управленческий опыт, нужно ориентироваться в мире практик и теорий, понимать чем они отличаются, какие имеют плюсы и минусы. Но человек, который всё это знает, и сам понимает, что каждая практика или метод — это лишь инструмент настройщика рабочего процесса.
Существует такой здоровенный и скучный стандарт CMMI, который во многом решает задачу, которая заявлена в статье. Он рассматривает процесс создания ПО и делит его на уровни зрелости — от полностью хаотичного до безумно организованного. В нём не описаны практики, конкретные советы и способы написания кода, есть только целевые задачи. Например, на втором уровне нужно обеспечить управление требованиями и управление конфигурацией — что-то в этом духе. (У них предполагается, что организация будет последовательно развивать свою систему, двигаясь к организации, но это не обязательно принимать как руководство к действию, можно просто понимать, чего тебе не хватает на очевидно твоём уровне).
Отличие этого стандарта от данной статьи в том, что им действительно можно воспользоваться как конструктором. Взять нужный уровень, посмотреть, какие процессы на нём должны быть в твоей системе управления разработкой, и под каждый процесс что-то внедрить. Этот набор целевых задач для каждого уровня согласован с существующими теоретическими достижениями в управлении, с процессными подходами и так далее, то есть, он хорошо работает как подсказка для конструирования.
Вот чего-то такого мне не хватило в статье, хотя в целом мне не с чем там принципиально поспорить, все практические советы написаны вполне по делу.
Практика показала, что страховым компаниям на этот риск абсолютно наплевать, и карту они готовы подделать, лишь бы ОСАГО купили у них.
При этом, не забывайте, в случае аварии они могут сказать вам, что вы не проходили осмотр, ваша карта подделана и никакой выплаты вы не получите (и страховая снова в шоколаде).
Так что дело ваше, я бы на вашем месте осмотр проходил, тем более что стоит это недорого и отнимает не больше часа времени, если с машиной всё в порядке.
Насчёт легальности. Видно, что ВК много работает в этом отношении, но стараясь усидеть на двух стульях. Значительная часть музыки закрывается от бесплатного доступа, но это касается в основном всякой новой, коммерчески актуальной продукции, по которой могут возникнуть претензии.
У ВК есть подписка на музыку, которая снимает все ограничения, и по сути это стриминговый сервис с легализацией контента, который вы слушаете.
Вот по поводу видео ничего сказать не могу.
Работа с фото, мессенджер, интерфейс для музыки (там, кстати, наладилось с легальностью), понятная механика работы пабликов, более понятный принцип формирования ленты — всё это в вк гораздо удобнее.