Главное Свежее Вакансии Образование
Выбор редакции:
631 4 В избр. Сохранено
Авторизуйтесь
Вход с паролем

Как ставить автономно выполняемые задачи и управлять проектами (работами) в условиях неопределенности

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

Привет коллеги, друзья и уважаемые четыре подписчика!

Представляю вам набор интересных тезисов (черновик тезисов) с ответами на вопросы кто виноват и что делать?

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

1> Что такое поставить задачу.

Поставить задачу это значит запустить (дать ход) деятельность по изготовлению определенного рабочего продукта.

2> Рабочий продукт - информ-объект / материальный объект в пространстве и времени сформированный в результате последовательных воздействий согласно порядку действий персонажа на входящий материал.

Рабочий продукт всегда является входящим материалом для следующих задач (работ) в производственной цепочке.

3> Совокупность рабочих продуктов дает конечный рабочий продукт. Соединяются они согласно плану сборки по утвержденной Архитектуре.

Что делает каждый рабочий продукт в общей архитектуре - это функция, и продукт называется “Компонент”.

Из чего состоит это продукт в материальном носителе, в какой метрике измеряется - это называется “Модуль”, этот модуль где-то дальше физически располагается

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

6> Понимание что нужно сделать по задаче - это то что можно будет “забрать” дальше для производства следующих задач, это всегда отчуждаемо, нормируемо, валидируемо.

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

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

Чем я могу вам читающим помочь, ну вот согласовывать задачи можно действуя по моей схеме - http://files.pavlyut.com/mindactions.v3.0.alpha1.3.png, как это делать я уже публиковал в ютубе https://www.youtube.com/watch?v=ErgNavOuCfo

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

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

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

Это пример как у вас работает процесс “изменений форм и соглашений”.

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

А теперь по продукту.

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

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

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

3. Все самое интересное на самом деле я упаковал в первую версию его WhitePaper’а. (да простит меня спарк, вайтпейперы тут я публиковать и обновлять не планирую, не место им тут, так что нечего меня банить, лучше сами зайдите и почитайте, говорят только сами описания того как я работаю имеют магическую силу озарений - http://www.pavlyut.com/posts/mjolnir).

Всем пис!

+1
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
DEVOPS OUR CING
H.H. and In P. Запуск в работу IT-проектов
Игорь 73985
В Питере - тире - ...

"Поэтому вы должны “согласовывать” задачи которые нужно исполнять с руководством (заказчиком) на языке понятном заказчику, "

Пример понятного "языка" - http://files.pavlyut.com/mindactions.v3.0.alpha1.3.png ( Александр, Вам не говорили, что Вы работаете в очень узкой нише и при этом сузили её сами? )
Ответить
Мьёльнир
Платформа для создания (технологических) продуктов
Александр Павлють
> В Питере - тире - ...

дратути

> "Поэтому вы должны “согласовывать” задачи которые нужно исполнять с руководством (заказчиком) на языке понятном заказчику, "
> Пример понятного "языка" - http://files.pavlyut.com/mindactions.v3.0.alpha1.3.png ( Александр, Вам не говорили, что Вы работаете в очень узкой нише и при этом сузили её сами? )

Понятный язык это не равно "укороченый" или "упрощенный" язык для аудитории которая им не владеет.

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

Типичная онотолоческая картина клиента который не понимает в принципе ничего что там за экраном - это все "сайт".

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

И как-то нужно вести коммуникацию внутри команды по каждому из этих понятий.

Ну и давайте конкретно - что на схеме вы считаете нужно убрать и почему. Аргументируйте.
Ответить
DEVOPS OUR CING
H.H. and In P. Запуск в работу IT-проектов
Игорь 73985
Но на самом деле, я проникся большим уважением. Нужно быть очень настойчивым, чётким и ясным в мыслях, не допускать никаких "неопределенностей" чтобы реализовать в "граните кода" подход: "Система Разделения Труда - это полностью осознанная целевая экономически выгодная деятельность, поделенная на операции, которые разделены на действия, они отнормированы, имеют эталонные показатели, замеряемы и информация о ходе каждого действия (по результативным его точкам) фиксируется и находится в информационной системе поддерживающей эту деятельность."

Но я не верю в возможность абсолютного следования этому.
Я подозреваю, что есть даже теоретические обоснования нецелесообразности и невозможности нормирования и измерений всего, бесконечная декомпозиция операций, структур обязательно приведет к издержкам. Вам говорили про такое? Я чего то неправильно говорю? У Вас есть четкие критерии, по которым легко найти предел? У Вас в методологии (кажется я уже спрашивал) не очень понятно как вписать "творчество". В сайтостроении уже давно нет творчества? :(
С другой стороны, а может действительно - зачем оно в сугубо утилитарных сущностях (вебсайтах для бизнеса). С творчеством это к Артемию Лебедеву ?
Ответить
Мьёльнир
Платформа для создания (технологических) продуктов
Александр Павлють
> Но на самом деле, я проникся большим уважением. Нужно быть очень настойчивым, чётким и ясным в мыслях, не допускать никаких "неопределенностей" чтобы реализовать в "граните кода" подход: "Система Разделения Труда - это полностью осознанная целевая экономически выгодная деятельность, поделенная на операции, которые разделены на действия, они отнормированы, имеют эталонные показатели, замеряемы и информация о ходе каждого действия (по результативным его точкам) фиксируется и находится в информационной системе поддерживающей эту деятельность."

Так все и есть, благодарю за респект.


> Но я не верю в возможность абсолютного следования этому.

Слово "вера" и "абсолюнного" встречаются в определенной литературе, как привало ничего не имеющей к конкретике. Увы проектировать надо, мактеты делать надо, утвреждать их надо, все это делать надо. Релизы офомлять надо. Фиксы оформлять надо. Цели ставить надо. Прогресс оценивать надо. Результаты измерять надо. Я это заставляю делать. Вы можете этому не следовать. В этом моя гарантия результата и его качества. Я делюсь ей с коллегами и призываю работать качественно а не в болоте понятийной картины. Порядок бьет хаос.

> Я подозреваю, что есть даже теоретические обоснования нецелесообразности и невозможности нормирования и измерений всего, бесконечная декомпозиция операций, структур обязательно приведет к издержкам. Вам говорили про такое? Я чего то неправильно говорю? У Вас есть четкие критерии, по которым легко найти предел?

Давайте для начала вы приведете пример конкретный, измеряемый, чтобы я мог дать на него конкретный измеряемый и агрументированный ответ. Сейчас мне это сделать сложно потому что я не вижу вопроса а только мнение, и вопросы только подразумеваются - коллега, дайте фактуру, и мы как раз ее разберем на делали. Я не понимаю что такое "предел". Элемент на экране это предел декомпозиции? В чем ваша обеспокоенность конкретно?

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

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

> У Вас в методологии (кажется я уже спрашивал) не очень понятно как вписать "творчество". В сайтостроении уже давно нет творчества? :(

Что такое творчество - если у человека есть задача разместить на экране 5 элементов, в чем ограничено его творчество предложенных варианвто как это сделать лучше?

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

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

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

Это прозрачность и отвественность - после некоторого итерационного взаимодействия люди начинают работать "молча" и "твроить". Процесс идет.

> С другой стороны, а может действительно - зачем оно в сугубо утилитарных сущностях (вебсайтах для бизнеса). С творчеством это к Артемию Лебедеву ?

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

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


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

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

=)
Ответить
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.