Category: литература

Фото

Это исторически заглавный пост

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

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


Про изменение френд-политики.

Моя почта:
videoelektronic
(собака)yandex.ru


Счетчик PR-CY.Rank

Счетчик PR-CY.Rank

Счетчик PR-CY.Rank
promo videoelektronic may 5, 2018 21:48 2
Buy for 40 tokens
А скачать (абсолютно бесплатно!) можно тут: https://play.google.com/store/apps/details?id=com.skvgames.GemStripes
The Dungeon Again!, Hell

Виды контрактов в заказной разработке

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

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

Для начала, перечислим традиционные модели взаимодействия клиента и исполнителя: Контракт с фиксированной ценой - Fixed price (FP), Повременная оплата - Time and material (T&M), Аутстафф - Outstaff.

Контракт с фиксированной ценой

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

Ремарка: документ "требования" часто также называют "техническое задание", ТЗ, что не вполне верно. По ГОСТу требования есть часть ТЗ. Впрочем, пожалуй - самая важная.

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

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

Отмечу, что только исполнитель решает, полны ли и детальны ли предоставленные заказчиком постановочные документы. В целом, если требования неполны, не всегда обязательно настаивать на их доработке до блеска. Иногда неполнота постановки является хорошим аргументом для контрактации по T&M и выполнения работ по agile.

Если требования отсутствуют или неполны, применяются две схемы контрактации.

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

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

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

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

Контракт T&M

Строго говоря при таком виде контракта стоимость работ не может быть оговорена на старте. Тем не менее, редкий заказчик готов оперировать оценкой стоимости работ в диапазоне от нуля до бесконечности. Как правило, исполнитель всё же называет опорную стоимость и срок. Иногда оговаривается безусловная максимальная цена и ключевые временнЫе точки в проекте, к которым должны быть сделаны релизы с той или иной функциональностью.

Контракты T&M довольно вариативны. В пределе при работе по такому контракту исполнитель может вообще не нести ответственность за сроки и стоимость, тогда схема приближается вплотную к аутстаффу (см. ниже) и, к примеру. менеджер проекта находится на стороне клиента. В другой крайности контракт T&M представляет собой практически fixed price контракт, но с ослабленными требованиями к составу релизов, стоимости и срокам. В такой контракт хорошо вписывается agile подход в той или иной его инкарнации. Например, жёсткий план проекта может быть заменён на беклог с уточнением состава релизов по ходу проекта. Впрочем, по сути, ничто не мешает делать то же самое и в проекте с фиксированной ценой. Другое дело, что в fix price проекте любая замена в составе функциональности проекта должна проходить жёсткую процедуру запроса на изменение (ЗИ, CR), а в T&M проекте схема согласования такого изменения может быть куда более расслабленной (в частности, не включать в себя точный подсчёт изменения сроков и стоимости проекта).

Аутстафф

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

Стороны и ресурсы

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

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

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

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

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

Очень важно в том или ином объёме подключать со стороны заказчика системного администратора или сотрудника группы devops. В противном случае все релизы и интеграции обойдутся команде в цистерны крови и километры измотанных нервов.

Ценность разработчиков со стороны заказчика, как правило, невелика, хотя, опять же, бывают варианты.

Консалтинг и точка принятия решений

Постулат: Решение принимает тот, кто за него платит. То есть - заказчик.

Постулат: Вы всегда консультируете заказчика. Вас потому и наняли.

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

  • Умение управлять проектом и достичь результата в срок и деньги. (Вы продали проектное управление)

  • Умение проектировать программные решения такого типа. (Вы продали архитектуру и технические решения)

  • Умение работать с бизнес-кейзами такого типа. (Вы продали бизнес-консалтинг.)

В сознании заказчика присутствует какой-то образ вашей компании. И какая-то оценка вас как носителя знаний по этим трём направлениям.

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

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

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

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

Далее можно:

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

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

  • Молча продолжить работу, имплементируя неправильное решение заказчика (Вы же предупредили? Три раза? Он не внял? Это его решение.), но работая на снижение своих рисков - не допуская дебиторки, более чётко относясь к формальной стороне проекта (документам, актам и пр.)

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

Если такая ситуация (принятие заказчиком самоубийственного решения) случилась на проекте с заказчиком-стартапом - бегите.
Фото

Про "ПРО"

Свежее дыханье сентября
Раскрывает дверцы и оконца,
Но в Уэльсе собрались не зря
Все, кому не в радость мир и солнце.

Наша ширь распаханных полей
И лесов нехоженые тропы,
Словно шило в заднице у всей
Маленькой зажравшейся Европы,

Не скрывая ненависть и злость,
Точат клюв стервятники из НАТО.
Им Россия - словно в горле кость,
Словно прыщ на лбу - наш мирный атом.

Потому что здесь назло им всем
Украшая милые просторы,
Во поле стоит наш «Тополь-М»,
Как апофеоз российской флоры.

Он стоит, качаясь на ветру,
Над согретым солнцем буераком,
Только шум ветвей не по нутру
Пресловутым НАТОвским воякам.

И они, как стая злых ворон,
Что кружат в угоду мракобесу,
Обложили нас со всех сторон,
Угрожая миру и прогрессу.

Мы, конечно, мирная страна,
Но терпеть их силы нету больше.
Развелось их всюду до хрена,
В том числе – и в Латвии, и в Польше.

А теперь со злобой ледяной,
Выгнув колесом кошачью спину,
Заодно с бандеровской шпаной
Точат зуб они на Украину!

Что же делать? Кто подаст совет,
Как разумней поступить нам все же?
Думаю, что есть один ответ,
И другого быть никак не может!

Ради мира на земле своей,
Мы в ответ под гулкий зов набата
Разведем в России голубей
И запустим их по странам НАТО!

Пусть летят по небу сизари,
Мирные доверчивые пташки,
Чтобы от зари и до зари
На Европу сбрасывать какашки.

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

Чтоб однажды утром по весне,
Как по мановению факира,
Вся Европа – по уши в говне,
А над ней весь в белом - голубь мира!

Александр Вулых.
http://www.vulykh.com/creation/?section_id=18&element_id=249

год дракона

БЕЗ ПАМПЕРСОВ НЕ ЧИТАТЬ !!! ВЫДЕРЖКИ ИЗ СОЧИНЕНИЙ ШКОЛЬНИКОВ

Оригинал взят у ai_zhilin в Плоды реформы образования
Оригинал взят у grimnir74 в БЕЗ ПАМПЕРСОВ НЕ ЧИТАТЬ !!! ВЫДЕРЖКИ ИЗ СОЧИНЕНИЙ ШКОЛЬНИКОВ
XkgEE2gxnjU

1. Трактор мчался по полю, слегка попахивая…
2. Летом мы с пацанами ходили в поход с ночевкой, и с собой взяли только
необходимое: картошку, палатку и Марию Ивановну.

Collapse )
Фото

Публикуется перепост, как поздравление с Днём Рождения!

Оригинал взят у kino_sssr в АТ - АТтикус
Аттикус Финч

Это была даже и не книга - роман-газета. Впервые я ее прочитал лет в 8, почти ничего не понял, но книга явно пришлась по душе - и позже я ее перечитал. Не один раз.
Это - "Убить пересмешника" Харпер Ли
Аттикус Финч - один из главных героев, адвокат, отец тринадцатилетнего Джима и Луизы - первоклассницы, от лица которой идет повествование.
Необыкновенный человек. Необыкновенная книга. Не было другой книги в моем детстве, которая произвела бы на меня столь сильное впечатление, как "Убить пересмешника". Она потрясала меня при каждом чтении.
И еще раз потрясла, когда я перечитал ее во взрослом возрасте...

ат

Collapse )
шпионы

Неужели я рассказал какую-то государственную тайну в стихах?

Утренняя лента Яндекса заставила меня вернуться к теме российских шпионов. Пишу уже без кавычек, так как сам Путин объявил о работе этих людей:

"Я с ними встречался, - сказал глава правительства, отвечая на вопрос журналистов в резиденции украинского президента в Форосе. - Мы говорили о жизни".
"Пели, но не в караоке, а под живую музыку, пели "С чего начинается Родина", другие песни такого содержания".
Collapse )

Собственно, я бы не стал сейчас в своём ЖЖ переписывать ТОП-повые новости дня, если бы к этому меня не подвиг интересный эксперимент с поисковиком Яндекс.ру
Дело тут в том, что меня давно терзают смутные сомнения по поводу предвзятости и управляемости алгоритмов поиска этой пока самого популярной в нашей стране поисковой системы. Периодически я проверяю её на своих собственных сообщениях в Интернет.
ТОП-овая тема "про шпионов-разведчиков" дала повод проверить http://www.yandex.ru/ , как ресурс ищет мои собственные сообщения. Как раз кстати, все мои сообщения на эту тему оказались в стихах. Не ахти какие стихотворения, но они оригинальны, а значит должны без труда занимать первые строки при поиске по значительным отрывкам. 
Собственно, я брал текст из своих постов 
Про "русских шпионов" замолвите слово... (доля шутки)
Про "русских шпионов" замолвите слово... (2-я доля шутки)

Брал, например, такие фразы: 
"Но нас не сломить им джинсами Мы все тут почти Дзержинские"
"Пусть в Пентагоне компьютеры Им не понять Россию И мудрое наше правительство"
"Чётко отдала начальнику честь Желаю здравия! Можно присесть"

Можете сами дальше экспериментировать с данным текстом, если есть желание. Результат один - на первой странице поисковика никаких ссылок на мой ЖЖ ! 
В то время, как http://www.google.ru/ , который можно открыть прямо из незамечающего меня отечественного поисковика, естественно помещает меня во главу списка поиска! 

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