Бдительный телефон

Прочитал любопытную заметку о том, что в магазинах частенько пробивают суммы на кассах бОльшие чем указаны на ценниках. Это легко объяснить общим бардаком в магазине (а не только желанием обмануть), но суть в том, что это не законно. Т.е. если на ценнике написано 100 р. и вы взяли товар с полки, вам обязаны пробить чек на эту сумму. Даже если цена этого товара уже 500 р., но "девочки не успели сменить чек". Публичная оферта и все такое. Чтобы доказать свою правоту в суде достаточно сфотать ценник...

Так вот, родилась у меня идея одного приложения для телефона с фотоаппаратом.

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

Как и для любой хорошей бизнес-идеи надо рассмотреть ряд факторов:
1) Какую проблему решает программа? Проблему потенциального надувательства в супермаркетах. Выполнить подобную проверку самому практически невозможно. Где-то записать все ценники и сверить их с чеком очень и очень сложно. Максимум что делают люди - пробегают глазами по чеку и смотрят нет ли каких-то явно левых товаров, которые они не покупали. В случае с программой любая разница будет бросаться в глаза и давать повод и основания для детального разбирательства.
2) Какие сложности в ее реализации? Нужно аккуратно решить проблему распознавания цен. На ценниках обычно много разных цифр, они разного шрифта и т.п. Нужно выбрать правильное число, качественно распознать и т.п. Однако - все реально.
3) Кому такая программа нужна? Людям, которые не прочь покачать права в магазине, но не имеющие для этого оснований. :)
4) Как развивать программу дальше? Например, сделать, распознование названий товаров. Ведение базы данных покупок. Когда вы придете через неделю в тот же Ашан и возьмете те же помидорчики что и в прошлый раз, система может сообщить, что они подорожали на 20 рублей. Или подешевели. В любом случае - информация к размышлению и повод это дело обсудить :).

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

Рекурсивные откаты

Мысль!
Бывают откаты обычные: приходит Представитель Исполнителя (ПИ) к Представителю Заказчика (ПЗ) и говорит - давай ты сделаешь так, что наша фирма выиграет ваш тендер на 50 лимонов, а я тебе за это дам 5 лимонов!
Схема стандартная, но какой выигрыш от этого для ПИ? Только один - возможность для своей фирмы работать по выигранному тендеру.
А вдруг бывают рекурсивные откаты? ПИ приходит к ПЗ и говорит: давай я сделаю так, что наша фирма предложит тебе откат в 5 лимонов за то, что наша фирма выиграет тендер на 50 лимонов, но ты часть этого отката (2 лимона) отдашь мне!
И тогда для ПИ уже совсем не важно - хороший тендер или плохой, выполнит ли его компания контракт или нет - свое он уже получил. Для ПИ есть стимул дать откат побольше (чтобы процент с него получить пожирнее), и ПЗ доволен! В минусе оказываются только компания-заказчик и компания-исполнитель.
Схема чисто гипотетическая, в голову пришла только что. Все совпадения, сами понимаете, случайны. ;)
Симптомы рекурсивных откатов:
1) решения об откате со стороны исполнителя принимает человек, не являющийся владельцем бизнеса, не лояльный бизнесу, чей успех не связан с успехом его компании напрямую.
2) размер отката велик по сравнению с "конкурентами" (знаете какая конкуренция на рынке откатов в госсекторе? Вот и я не знаю!)
3) выигранный тендер не является привлекательным для исполнителя - для его реализации не хватает компетенций и ресурсов.

Любопытно, да?

Оптимизация расходов и борьба за ТК

Буквально неделю назад руководство холдинга предложило всем своим сотрудникам подписать дополнительные соглашения к трудовому договору, в которых размер зарплаты уменьшен на 50%. Вся зарплата была белой, а теперь планируется стать серой. При этом руководство нашей компании (входящей в холдниг) клятвенно заверяет, что все сотрудники будут получать ровно столько же, сколько и раньше. И, что самое интересное - "по белому", через ежемесячные премии. Что это позволит сэкономить на налогах. Естественно, в предъявленном каждому сотруднику доп. соглашении ничего про премии не говорится, и инсайдерская информация свидетельствует, что в остальном холднинге ни про какие "белые премии" никто не говорил. Подробные расспросы руководства привели к оговорке с их стороны, что если ситуация ухудшится, то премии могут стать серыми. Призывали всех "поверить на слово и подписать соглашение".
Естественно, я отказался (таких оказались единицы). Что будет с "отказниками" - неизвестно. Туманно намекали на "беседы с кадровиками и безопасниками". Может пытались напугать? Так я тоже могу кого угодно напугать :). Посмотрим что из этого выйдет...
Я ведь готов пойти навстречу руководству, потому что сокращение налогов - это здорово, и я полностью согласен перейти на схему 50% оклад, 50% белая премия, если это будет зафиксировано в трудовом договоре. Однако, обойдя ряд инстанций я получил отказ: "пункт о премировании мы включить в доп. соглашение не можем. Никому не включали и Вам не будем". Руководство обещает сделать "положение о премировании" в рамках компании. Но как его примут, так его и отменят - работников никто спрашивать не будет.

Мои прогнозы, по всему происходящему:
1) Данный шаг - попытка сэкономить, когда дело дойдет до сокрашений.
2) А дело до них дойдет в лучшем случае весной (март-апрель), в худшем - в конце явнваря, когда будет понятно, что новых проектов нет, а людей просто нечем занять.
3) Официально сокращенные люди получат компенсации исходя из половины их фактической зарплаты. И все по закону.

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

Манифест капиталиста

Наткнулся в блоге "эффективного человека" на цитату из книги Айн Рэнд “Атлант расправил плечи”. Процитирую его здесь

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

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

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

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

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

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

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

Это моя мораль, и я не признаю никакой другой.

Что мне в этом тексте не понравилось.
"Справедливая оценка труда - залог стабильности экономики страны, залог благополучия ее граждан". Что такое "справедливая оценка"? Что является объективным критерием справедливости? Для участкового врача зарплата в 6 тысяч руб. - это справедливая оценка труда? а 60 тысяч? Где грань?

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

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

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

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

Насчет абзаца про "обоюдное добровольное согласие" о "покупке продукции". Бандит на дороге может спросить - "жизнь или кошелек?". Жертва обычно добровольно, по собственному согласию, выбирает жизнь, отдавая кошелек. Монополист на рынке нефти может сказать - "хотите - покупайте бензин за 30 руб./литр, не хотите - не покупайте и ходите пешком. Вы - свободны делать свой добровольный выбор". Тоже самое с зарплатами и работниками. Если в городе безработица и 3 человека на вакансию, то люди "добровольно согласятся" работать за гроши. Будет ли это "справедливой оценкой"? Не знаю. Зато добровольной.

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

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

Цена специалиста

Сегодня пришла в голову мысль, что ценность специалиста в компании складывается из двух факторов
1) количество пользы которое он приносит, работая в компании
2) объем убытков, которое компания понесет, если этот человек уйдет из компании

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

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

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

Проекты быстрой "разморозки"

На днях уволился коллега – ведущий разработчик и архитектор. Он вообще товарищ сознательный и написал «завещание», в котором перечислил проекты, в которых он участвовал за последние пару лет, адреса к исходникам в системе контроля версий, а также имена тех кто «в теме» - коллег, активно участвовавших в этих проектах. Мысль, в общем-то, полезная. У нас бывают ситуации, что для проекта, успешно завершённого год-два назад заказчик хочет доделать ещё какую-нибудь фичу, и даже готов хорошо заплатить за это. И тут есть два варианта развития событий

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

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

• Найти материалы по проекту – требования (если они вообще были), исходники последней версии (трясти админов).
• Напрячь людей на вхождение в курс дела. Аналитикам выдать требования, попытаться выяснить, насколько вообще эти требования актуальны. Разработчиков напрячь развёртыванием исходников и необходимого окружения (в случае старых разработчиков, рабочее и тестовое окружение может уже быть где-то развёрнуто).
• Выждать время пока аналитики и разработчики вникнут в предметную область и разберутся с уже созданной системой, и потом маленькими шажками выяснять насколько затратны новые хотелки заказчика. Люди которые создавали данную систему, как правило, могут быстро оценить – насколько реализуемо то или иное улучшение \ изменение. Новые люди могут не знать тонкостей архитектуры и особенностей реализации (кривых и сложных мест).

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

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

Предлагаю опустить обсуждение вопроса «кто виноват» и сразу перейти к «что делать».

На лицо стандартная ситуация по управлению рисками.

Риск. С уходом ведущих разработчиков стоимость «размораживания» проекта существенно возрастает, а шансы на успешную модификацию системы – падают.

Индикатор риска. Текущий проект завершается с большим набором новых «хотелок» заказчика «на будущее», но прямо сейчас покупать развитие проекта заказчик не хочет \ не может.

Способ избежать риска.

Не отпускать разработчиков :) . К сожалению это практически нереально – людям может просто захотеться сменить обстановку. Поэтому серьёзно на это рассчитывать не стоит.

Способы ослабить риск.

Вот тут начинается самое интересное.

Способ первый. При увольнении, ведущий разработчик (или архитектор) передаёт свои знания о проектах другим разработчикам (архитекторам). Прямо садится и рассказывает где что и как сделано в этой системе, почему именно так, а не иначе, рассказывает про предметную область, указывает на проблемные и сложные не очевидные места в коде, архитектуре, базе данных. Все это сопровождается показом исходников, а слушающий товарищ все это дело конспектирует, задает вопросы – входит в курс дела. Можно даже рассказать об известных будущих «хотелках», которые, скорее всего, заказчик купит в будущем. Чтобы мотивировать слушателя, ему сообщается, что в случае чего, именно он станет ведущим разработчиком (архитектором) на развитии данного проекта. Происходит прямая передача знаний. Аналитики могут поступать аналогичным образом.

Когда этот подход можно применять? Во-первых, когда текучка не очень большая. Если знания передадутся из уст в уста 3 раза, то от них ничего уже не останется. Должна существовать большая вероятность что тот, кому передают знания в первый раз как раз и будет заниматься развитием проекта. Во-вторых, сам проект не должен быть сделан откровенно плохо. Потому что перспектива доделывать невероятно кривой и глючный проект, в котором даже малейшее изменение может вызвать огромный поток незапланированных работ по «переклейке заплаток» - отпугнет любого нормального разработчика. Он вас просто лесом пошлет с таким «наследием» и уволится вслед за первым. :)

Способ второй. В процессе работы над проектом требования и техническая документация (архитектура и дизайн) поддерживаются в актуальном состоянии. При завершении проекта документация проверяется. В результате должен появиться комплект документов, по которым человек даже не знакомый с проектом сумеет быстро вникнуть в суть дела. Тут очень важно понять одну вещь. В реальной работе написание документации и требований служит одной важной цели – добиться общего видения разрабатываемой системы у всех участников проекта. Если участников 2-3 человека и они к середине проекта прекрасно себе представляют как должна выглядеть и как должна работать система, и это видение совпадает с видением заказчика, то написание подробной документации превращается в пустую трату времени. Если до финиша остался месяц, и все разработчики в курсе предметной области, архитектуры, и т.п., то тратить деньги проекта на какое-то описание (которое может и не понадобиться) – жаба задушит :). Под описанием я не обязательно понимаю какие-то word’овские документы. Это могут быть требования в какой-то системе управления требованиями, use-cases, диаграммы классов, описание архитектуры, база знаний «заплаток» и т.д. В маленьком и «понятном» проекте есть соблазн пожертвовать техническим описанием в угоду эффективности. Для слаженной команды требования могут быть не очень четкими, полными или актуальными – у всех есть общий контекст. Для новичка у которого не будет контакта с «хранителем сакрального знания» о проекте - четкая, полная и актуальная документация просто необходима.

Получается, что вложение сил в поддержание хороших требований и дизайнерской документации – это вложение в потенциальное будущее. Повышение той самой «сопровождаемости» (maintainability) программного продукта. Достижение стратегических целей в ущерб тактическим успехам. Страховка. И забота эта, прежде всего, топ-медеджмента. Потому что maintainability не является целью руководителя проекта. Его задача – уложиться в установленные ограничения. То, что поддержка и развитие продукта будет стоить дорого – это просто новое ограничение, в которое он постарается уложиться. Потом. Если оно вообще случиться. Снижение стоимости поддержки и развития продукта – задача топов, занимающихся стратегией.

Итого. Проблема передачи знаний о проекте довольно актуальна. Прямая передача знаний от разработчика к разработчику – самый дешевый и эффективный способ. Но он не всегда срабатывает. Более надежный, но дорогой способ – поддержание в актуальном состоянии требований и технической документации. Выбор того или иного способа должен быть осознанным. Чтобы удешевить процесс ведения требований необходима удобная система управления требованиями (вот так банально, да). Но это совсем другая история...