KG
Это же крупная компания, секретарь забукал митинг через пару месяцев :)
просто нет свободных переговорок - знакомо всем
Size: a a a
2019 October 18
KG
я вобще думал предложить своему CIO брать по 500 рублей хотя бы за час переговорок
SB
просто нет свободных переговорок - знакомо всем
Есть, подозреваю проблема в несовместимости наших расписаний :)))))))))))
KG
думаю ебитда бы серьезно улучшилась
KG
Есть, подозреваю проблема в несовместимости наших расписаний :)))))))))))
оно и понятно. они солнца не любят же
SB
оно и понятно. они солнца не любят же
Шах и мат! :)))
2019 October 19
KG
вместо тысячи схем подари рафаэлло (с)
AL
ну да че то не очень. ложикал от физикала вроде отличается только тем что ложикал может быть в любой системе, а физикал это в конкретной
The logical architecture model of a engineered system of interest (SoI) is composed of a set of related technical concepts and principles that support the logical operation of the system. It may include a functional architecture view, a behavioral architecture view, and a temporal architecture view. Other additional views are suggested in architecture frameworks, depending on the domain.
[https://www.sebokwiki.org/wiki/Logical_Architecture_Model_Development]
A physical architecture model is an arrangement of physical elements, (system elements and physical interfaces) that provides the solution for a product, service, or enterprise. It is intended to satisfy logical architecture elements and system requirements ISO/IEC/IEEE 26702 (ISO 2007). It is implementable through technological system elements. System requirements are allocated to both the logical and physical architectures. The resulting system architecture is assessed with system analysis and when completed becomes the basis for system realization.
[https://www.sebokwiki.org/wiki/Physical_Architecture_Model_Development]
[https://www.sebokwiki.org/wiki/Logical_Architecture_Model_Development]
A physical architecture model is an arrangement of physical elements, (system elements and physical interfaces) that provides the solution for a product, service, or enterprise. It is intended to satisfy logical architecture elements and system requirements ISO/IEC/IEEE 26702 (ISO 2007). It is implementable through technological system elements. System requirements are allocated to both the logical and physical architectures. The resulting system architecture is assessed with system analysis and when completed becomes the basis for system realization.
[https://www.sebokwiki.org/wiki/Physical_Architecture_Model_Development]
AL
В этот момент хорошо вспомнить разницу между КД, ТД, РД и ИД =)
DZ
Текущая ситуация, поясню - мы как бы "стартап внутри корпорации". Корпорация нам даёт денег на решение их задач быстро и красиво, и не заставляет подчиняться всем правилам, кроме, разумеется, безопасности. Нам надо научиться говорить с ними на одном языке, решать общие задачи, и при этом "быть собой". Да, я вот такой вот "хиппи на уолл-стрит".
Сергей, из опыта очень похожей задачи — порекомендовал бы такие приоритеты выделить:
1) Постоянно думать о своей бизнес-актуальности. Надо выкатывать видимый всем результат, полезный именно для бизнеса. Нельзя оставаться «экспериментальным подразделением» — это временная фаза развития, неустойчивая конструкция. Обязательно успеть вырасти в «настоящее» подразделение.
2) Позаботиться о бюджете и зафиксировать performance metrics. На первый год бюджет непоказателен — возможно, просто дали денег на волне инновационного хайпа. Второй год получить намного сложнее.
То же и с метриками — сначала прокатывает «ну вы делайте, там посмотрим». Но на годовом performance appraisal / budget review надо уже более существенное что-то иметь.
На мой взгляд, лучший вариант — это финансирование в формате программы.
3) Коммуникации. Приоритет — сотрудничество, а не революции и снобизм. Очень важно строить сразу рабочие отношение по всем направлениям. На это, реально, уходит основная часть времени (экспериментального директора).
4) Поделить территории. Важно не вступать в рубилово за каждую задачу с традиционной организацией, но и не придумывать себе творческие задачи. Самое продуктивное — на уровне governance поделить территории. Хорошо работают две системы координат — по ЖЦ систем (забирать себе прототипы и все новое) и по делению на слои (system of record, .. differentiation, ..).
5) Встроиться в глобальный процесс. Имеет смысл искренне понять ожидания безопасников, риск менеджмента, глобальных it-шников . И после этого встраиваться во framework — обычно он достаточно глобален, чтобы не мешать вписать свои детали. А где это совсем невозможно — надо обсуждать создание контролируемых песочниц, автономий. Важно понимать, что «дырки в заборах» все равно прикроют — а вот проходы и калитки можно и нужно строить. (Hint: надо влезать в работу профильных комитетов и помогать формировать эти политики. И это отъест большую часть времени неизбежно).
* * *
Буду рад обсудить / раскрыть подробнее, если будут вопросы!
1) Постоянно думать о своей бизнес-актуальности. Надо выкатывать видимый всем результат, полезный именно для бизнеса. Нельзя оставаться «экспериментальным подразделением» — это временная фаза развития, неустойчивая конструкция. Обязательно успеть вырасти в «настоящее» подразделение.
2) Позаботиться о бюджете и зафиксировать performance metrics. На первый год бюджет непоказателен — возможно, просто дали денег на волне инновационного хайпа. Второй год получить намного сложнее.
То же и с метриками — сначала прокатывает «ну вы делайте, там посмотрим». Но на годовом performance appraisal / budget review надо уже более существенное что-то иметь.
На мой взгляд, лучший вариант — это финансирование в формате программы.
3) Коммуникации. Приоритет — сотрудничество, а не революции и снобизм. Очень важно строить сразу рабочие отношение по всем направлениям. На это, реально, уходит основная часть времени (экспериментального директора).
4) Поделить территории. Важно не вступать в рубилово за каждую задачу с традиционной организацией, но и не придумывать себе творческие задачи. Самое продуктивное — на уровне governance поделить территории. Хорошо работают две системы координат — по ЖЦ систем (забирать себе прототипы и все новое) и по делению на слои (system of record, .. differentiation, ..).
5) Встроиться в глобальный процесс. Имеет смысл искренне понять ожидания безопасников, риск менеджмента, глобальных it-шников . И после этого встраиваться во framework — обычно он достаточно глобален, чтобы не мешать вписать свои детали. А где это совсем невозможно — надо обсуждать создание контролируемых песочниц, автономий. Важно понимать, что «дырки в заборах» все равно прикроют — а вот проходы и калитки можно и нужно строить. (Hint: надо влезать в работу профильных комитетов и помогать формировать эти политики. И это отъест большую часть времени неизбежно).
* * *
Буду рад обсудить / раскрыть подробнее, если будут вопросы!
DZ
Вот хорошая книга по тематике. В реальности многое придется напильником по ситуации, но она акценты расставляет глобальные.
https://www.amazon.com/Startup-Way-Companies-Entrepreneurial-Management/dp/1101903201
https://www.amazon.com/Startup-Way-Companies-Entrepreneurial-Management/dp/1101903201
GK
Denis Денис, спасибо! Ёмко и точно.
AS
Denis Zarin
Сергей, из опыта очень похожей задачи — порекомендовал бы такие приоритеты выделить:
1) Постоянно думать о своей бизнес-актуальности. Надо выкатывать видимый всем результат, полезный именно для бизнеса. Нельзя оставаться «экспериментальным подразделением» — это временная фаза развития, неустойчивая конструкция. Обязательно успеть вырасти в «настоящее» подразделение.
2) Позаботиться о бюджете и зафиксировать performance metrics. На первый год бюджет непоказателен — возможно, просто дали денег на волне инновационного хайпа. Второй год получить намного сложнее.
То же и с метриками — сначала прокатывает «ну вы делайте, там посмотрим». Но на годовом performance appraisal / budget review надо уже более существенное что-то иметь.
На мой взгляд, лучший вариант — это финансирование в формате программы.
3) Коммуникации. Приоритет — сотрудничество, а не революции и снобизм. Очень важно строить сразу рабочие отношение по всем направлениям. На это, реально, уходит основная часть времени (экспериментального директора).
4) Поделить территории. Важно не вступать в рубилово за каждую задачу с традиционной организацией, но и не придумывать себе творческие задачи. Самое продуктивное — на уровне governance поделить территории. Хорошо работают две системы координат — по ЖЦ систем (забирать себе прототипы и все новое) и по делению на слои (system of record, .. differentiation, ..).
5) Встроиться в глобальный процесс. Имеет смысл искренне понять ожидания безопасников, риск менеджмента, глобальных it-шников . И после этого встраиваться во framework — обычно он достаточно глобален, чтобы не мешать вписать свои детали. А где это совсем невозможно — надо обсуждать создание контролируемых песочниц, автономий. Важно понимать, что «дырки в заборах» все равно прикроют — а вот проходы и калитки можно и нужно строить. (Hint: надо влезать в работу профильных комитетов и помогать формировать эти политики. И это отъест большую часть времени неизбежно).
* * *
Буду рад обсудить / раскрыть подробнее, если будут вопросы!
1) Постоянно думать о своей бизнес-актуальности. Надо выкатывать видимый всем результат, полезный именно для бизнеса. Нельзя оставаться «экспериментальным подразделением» — это временная фаза развития, неустойчивая конструкция. Обязательно успеть вырасти в «настоящее» подразделение.
2) Позаботиться о бюджете и зафиксировать performance metrics. На первый год бюджет непоказателен — возможно, просто дали денег на волне инновационного хайпа. Второй год получить намного сложнее.
То же и с метриками — сначала прокатывает «ну вы делайте, там посмотрим». Но на годовом performance appraisal / budget review надо уже более существенное что-то иметь.
На мой взгляд, лучший вариант — это финансирование в формате программы.
3) Коммуникации. Приоритет — сотрудничество, а не революции и снобизм. Очень важно строить сразу рабочие отношение по всем направлениям. На это, реально, уходит основная часть времени (экспериментального директора).
4) Поделить территории. Важно не вступать в рубилово за каждую задачу с традиционной организацией, но и не придумывать себе творческие задачи. Самое продуктивное — на уровне governance поделить территории. Хорошо работают две системы координат — по ЖЦ систем (забирать себе прототипы и все новое) и по делению на слои (system of record, .. differentiation, ..).
5) Встроиться в глобальный процесс. Имеет смысл искренне понять ожидания безопасников, риск менеджмента, глобальных it-шников . И после этого встраиваться во framework — обычно он достаточно глобален, чтобы не мешать вписать свои детали. А где это совсем невозможно — надо обсуждать создание контролируемых песочниц, автономий. Важно понимать, что «дырки в заборах» все равно прикроют — а вот проходы и калитки можно и нужно строить. (Hint: надо влезать в работу профильных комитетов и помогать формировать эти политики. И это отъест большую часть времени неизбежно).
* * *
Буду рад обсудить / раскрыть подробнее, если будут вопросы!
Тут вопрос вырасти или даунгрейдится? Беда всех внутренних чтартапов в том, что сложившиеся корпоративная культура пытается подмять эти ростки прогресса под себя. Тем самым превратить передовое подразделение в обычных винтиков системы работающих от забора и до обеда.
DZ
Тут вопрос вырасти или даунгрейдится? Беда всех внутренних чтартапов в том, что сложившиеся корпоративная культура пытается подмять эти ростки прогресса под себя. Тем самым превратить передовое подразделение в обычных винтиков системы работающих от забора и до обеда.
В начале пути оно не передовое, а просто экспериментальное -- очень разные вещи.
AS
Нет оно именно передовое. В стартапы идут лучшие, которые больше не могут и не хотят работать неэффективно. Ради этого люди готовы идти на риск.
А вы говорите, что результатом такого поведения будет то, что их просто встроят в существующую гнилую систему. Когда как задача ровно обратная - систему перестроить в конечном счете. А эксперименты должны быть неотъемлемой частью развития любого бизнеса
А вы говорите, что результатом такого поведения будет то, что их просто встроят в существующую гнилую систему. Когда как задача ровно обратная - систему перестроить в конечном счете. А эксперименты должны быть неотъемлемой частью развития любого бизнеса
AS
Как только стартап встроился в существующую систему - он мертв
ВК
Нет оно именно передовое. В стартапы идут лучшие, которые больше не могут и не хотят работать неэффективно. Ради этого люди готовы идти на риск.
А вы говорите, что результатом такого поведения будет то, что их просто встроят в существующую гнилую систему. Когда как задача ровно обратная - систему перестроить в конечном счете. А эксперименты должны быть неотъемлемой частью развития любого бизнеса
А вы говорите, что результатом такого поведения будет то, что их просто встроят в существующую гнилую систему. Когда как задача ровно обратная - систему перестроить в конечном счете. А эксперименты должны быть неотъемлемой частью развития любого бизнеса
>в стартапы идут лучшие
што
што
AS
Ничаво
ВК
Я вот бывал и во внутренних и во внешних, видел там разное. Ультимативно утверждать насчет лучших или худших не берусь
d
только ситхи все возводят в абсолют