Датчики падения вроде как были в китайских GPS-трекерах «для стариков». Мы с ними работали уже пару лет назад. По идее, после падения, человек должен был в течение какого-то времени нажать на кнопку, иначе трекер отсылал СМС «в ситуационный центр», а сам начинал говорить громким голосом «я старый, больной человек, я упал, пожалуйста помогите мне».
С юридической точки зрения я каким-то образом должен «закрыть» выполнение технической поддержки. Каким-либо актом или протоколом. Если ко мне не обращался заказчик, он может сказать «работа не выполнялась».
С юридической точки зрения для меня договор закрыт и я могу не особо беспокоиться об оказании технической поддержки.
Я хотел сказать, что в данном случае нужны тоже какие-то заранее предусмотренные механизмы.
Интересно, как оценивать «бесплатные» услуги? То есть, я разработал программу/сайт в рамках контракта, получил все деньги и в рамках контракта оказываю техподдержку.
Проблемы могут возникнуть, а могут и нет. Деньги за будущую техподдержку я получил.
Статистика показывает, что пользователи могут быть незаинтересованы в новой программе:
— Не хотят чего-то нового;
— Не хотят каких-то метрик, который покажут неэффективность их работы;
— Не хотят инструментов, которые позволят получать свою копеечку в обход правил;
— Тупо боятся, что не справятся с новой программой.
Отсюда рождается поток жалоб с общим посылом «программа плохая, ничего не работает» (причём, конечный юзер мог даже не открывать программу вообще, а опираться на беседы в курилке), после чего начинается пляска перед конечными пользователями в попытке заинтересовать.
Собственно, в программе эта оценка не рассматривается.
В 120 километрах от города Ташкента, среди гор находится полу-заброшенный городок урановой промышленности. Из одной заброшенной шахты/штольни течёт прохладный ручей с чистой водой.
Местная легенда гласит, что один турист отправляясь в поход, набрал 6+ литров воды из этого ручейка и пил всю дорогу в походе. Местная легенда гласит, что через год он умер от лейкемии.
Добавил бы ещё всякие заброшенные урановые рудники, которые стали не нужны во время конверсии. Вагонетки и иное металлическое оборудование, которое контактировало с рудой должно хорошенько фонить.
В лихие 90-е много такого вывезли на металлолом. Да и по сей день валяются потенциально опасные конструкции в открытом доступе: (со знаком позирую радостный я 8 лет назад).
Знакомый всё боялся радиации и как-то проверил свой гараж каким-то военным дозиметр. Шкала была градуирована в миллирентгенах, дозиметр ничего не показал и он оставил его там же в гараже. Через некоторое время он нашёл геологический, более точный, дозиметр и пошёл вторично замерять радиацию. Стрелка начала дёргаться уже перед входом в гараж…
Путём недолгого поиска выяснилось, что так злостно фонит эталонный источник радиации в оставленном военном дозиметре.
Друзья сталкивались с похожими вопросами, частично смогли решить внедрением методологии «каждая задача является проектом». В каждой задаче, где участвует более одного юнита — формируется группа реализация проекта и выстраивается иерархия. В особо крупных проектах формируется RACI-матрица. К сожалению, народ жутко не любит бюрократию.
У нас в проектах часто возникала проблема «Менеджер vs исполнитель»: существует прослойка людей, которая не хочет брать на себя ответственность, а только необоснованно «умничает» вместо выполнения работ, чем вносит разлад в настроения рабочей группы. Если такой специалист близок к незаменимому — способов решения конфликта ничтожно мало.
С юридической точки зрения для меня договор закрыт и я могу не особо беспокоиться об оказании технической поддержки.
Я хотел сказать, что в данном случае нужны тоже какие-то заранее предусмотренные механизмы.
Проблемы могут возникнуть, а могут и нет. Деньги за будущую техподдержку я получил.
— Не хотят чего-то нового;
— Не хотят каких-то метрик, который покажут неэффективность их работы;
— Не хотят инструментов, которые позволят получать свою копеечку в обход правил;
— Тупо боятся, что не справятся с новой программой.
Отсюда рождается поток жалоб с общим посылом «программа плохая, ничего не работает» (причём, конечный юзер мог даже не открывать программу вообще, а опираться на беседы в курилке), после чего начинается пляска перед конечными пользователями в попытке заинтересовать.
Собственно, в программе эта оценка не рассматривается.
Местная легенда гласит, что один турист отправляясь в поход, набрал 6+ литров воды из этого ручейка и пил всю дорогу в походе. Местная легенда гласит, что через год он умер от лейкемии.
В лихие 90-е много такого вывезли на металлолом. Да и по сей день валяются потенциально опасные конструкции в открытом доступе: (со знаком позирую радостный я 8 лет назад).
Путём недолгого поиска выяснилось, что так злостно фонит эталонный источник радиации в оставленном военном дозиметре.
У нас в проектах часто возникала проблема «Менеджер vs исполнитель»: существует прослойка людей, которая не хочет брать на себя ответственность, а только необоснованно «умничает» вместо выполнения работ, чем вносит разлад в настроения рабочей группы. Если такой специалист близок к незаменимому — способов решения конфликта ничтожно мало.