Возможен и такой вариант, но, коллега, это уже далеко не «создание поля в БД», а некий многоступенчатый процесс, в составе которого имеется создание поля в БД, судя по описанию… А гугловый АПИ может не прикручиваться на режимном объекте, где нет инета, хотя на презентации всё было так сладко, даже через глючный Вай-Вай…
Именно поэтому управленец, принимающий решения, должен быть в курсе того, как и что будет реализовано, чтобы не подставлять себя, свою команду и организацию.
Вот прям плюсану. Если время есть — то однозначно берётся для более детальной проработки вопроса.
А ещё надо учитывать, что каждый вышестоящий уровень уменьшает названное исполнителем время где-то процентов на 5-10.
Программист сказал, что сделает за неделю, руководитель отдела назвал 6,5 дней, координатор уже рассчитывает на 6 дней… Директору докладывают, что всё будет готово к утру, с чем и поздравляют исполнителя, который теперь уже вынужден работать ночами!
Невыполнимых задач не бывает, есть только требующие значительного количества времени или другого ресурса (которого, естественно, в нужных объемах нет).
Руководитель/менеджер не хочет слышать «нет, невозможно», он обычно хочет видеть варианты (пусть даже укрупнённые), из которых он выбирает: хотите 5км вертикально? Нет проблем, за вертикальный асфальтоукладчик готов взяться Завод тяжелого машиностроения им.Кащенко, его создание займёт 10 лет, стоимость будет -надцать млрд, если всё ок — завтра приступаем, итого в 11 лет уложимся. А можем дёшево и сердито положить горизонтально, за неделю, ещё и в 8 раз больше.
Так и с ПО: получая задачу ты уже в голове (а лучше на листке) прикидываешь примерный объём работы, к концу совещания уже готов примерный план работ. Можно прикинуть сроки, лучше умножить на 2 или 3. Понятны задачи, что являются ключевыми, а на чём можно сэкономить и сделать после сдачи (а даже если не сделать — не критично).
Я одно время в одной интересной отрасли (не медицина, конечно, но попытка тоже даётся только одна) получал задачи класса «завтра едете туда-то, что делать — определяетесь на месте, задача должна быть выполнена». То, что нужна подготовка, предварительное обследование, планирование и прочее — никого не волнует… Две минуты на обдумывание, навскидку 2-3 возможных варианта исполнения, согласование одного из предложенных.
Партия сказала «Надо!», комсомол ответил «Есть!». Мотивируем сотрудников на выполнение невыполнимого. Приехали, обследовали, на месте принял/уточнил/согласовал решения, спланировали, развернулись, отработали, свернулись, уехали. Самое сложное для меня было так распределить и донести задачи, чтобы исполнители с ними справились. А самое страшное было то, что результат зависит ото всех: один накосячит — накроется работа всей команды. Но при этом я сам знаю всё, что должен сделать исполнитель и могу проверить/исправить его работу.
Но зато все довольны: и заказчик, и руководство, и непосредственные исполнители, т.к. выполнили «невыполнимое».
В этом был свой драйв =)
Вон, народ ставит ориентировочные сроки полёта на Марс, и стремится к ним! И даже если они просчитаются и отправятся на год позже — они всё равно отправятся на, мать его, Марс! А если сроки не ставить — работа не будет выполнена никогда.
Да, жаль, что часто управленцем является человек слабо разбирающийся в разработке… А как в такой ситуации можно разбивать задачу и делегировать её части компетентным сотрудникам — вообще не представляю.
Хуже того, на переговорах с заказчиком такой управленец уверен, что создать дополнительное поле в таблице — это работа на пол-года, а вот определить, например, что на картинке изображена машинка или котег — чё там думать, результат будет уже завтра, это же элементарно!
Может в бизнес-аналитики/тимлиды податься? Как раз работу ищу =)
Резюме: Быстро нахожу общий язык с людьми. Синхронно перевожу с языка заказчика на язык исполнителя и обратно. Умею понять заказчика и донести до него позицию исполнителя. Что не может сделать конечный исполнитель — сделаю вместе с ним, заодно обучу.
Коллега, прям больную тему задел. Есть и обратная сторона медали, я на год старше и всегда развивался «вширь».
Сейчас ищу перспективную компанию/команду, где умения будут оплачены и востребованы, в идеале — в полном объёме… Переезд? Нет проблем, хоть завтра.
Я бы сказал, что знания лишними не бывают, неизвестно где и как они пригодятся. Есть возможность учить математику в общем и машинное обучение в частности — учи. Но и интересную работу никто не запрещает искать =)
Считаю, что «правильность» реакции зависит от конкретной ситуации, используемого языка, окружения и т.д.
Если мы говорим про обычное прикладное ПО, то от себя могу сказать, что считаю п.4 неправильным, если иное не оговорено ТЗ. Во всех остальных случаях исключительная ситуация должна быть обработана и, как минимум, не должна приводить к потере/искажению данных.
Оооо… Вы слишком глубоко копаете, предметная область, спецификация… =)
Элементарный пример — поле, в которое должна быть введена цифра, например, целочисленное поле «кол-во»… Очепятываемся и, в зависимости от кучи факторов, получаем от нефатальной ошибки, до фатального вылета без сохранения =(
У нас в крае такая милая программа для сдачи данных в ПФР ходила (или до сих пор ходит): одна очепятка и фатал эррор с потерей данных. Хотя, судя по внешним признакам, можно было бы хотя бы в блок try… обернуть
Во-первых, считаю, главный метод — это честность. Очень много потенциальных заказчиков обожглись как раз на нечестном исполнении, после чего выбрали позицию «лучше купить готовый продукт, чем что-либо заказать».
Мне как-то один исполнитель очень долго доказывал, что система оповещения по электронной почте (вставить в функцию логов несколько строк для отправки уведомления в случае появления критических ошибок) из Java-приложения — это титанический труд, который как минимум удвоит стоимость и учетверит объем работы. Пришлось немного процитировать RFC (если просто на сокетах писать), ну либо предложил воспользоваться имеющимся в Java классом. Исполнитель негодовал.
Часто исполнители нагло пользуются незнанием заказчика. Это не хорошо. При чём это касается не только нашей отрасли, менталитет у нас что-ли такой: кинь ближнего своего, ибо не ведает он…
Только вчера столкнулся с ситуацией, когда тестовый набор отличается от реальных данных, пришлось фактически переписать значительный кусок программы =)
Мне кажется, что статья описывает скорее работу кодера, но не программиста.
Это, считаю, как оценивать работу художника по количеству мазков или ставить над ним камеру и учитывать только время касания холста кистью. Ну и, конечно, не оплачивать те мазки, поверх которых были сделаны другие…
С другой стороны, очень часто наблюдаю ситуацию полнейшей незаинтересованности исполнителя в реализации проекта и, как следствие, попытки потом прикрываться сознательно плохо составленным ТЗ. А сколько раз я сталкивался (в роли эксперта при приёмке) с позицией исполнителя «в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
Я всегда стараюсь сесть вместе с заказчиком и постараться вместе с ним разобраться, что же всё-таки нужно получить в итоге, расписываются плюсы и минусы на перспективу и т.д. Вот тогда идёт работа на результат. Тогда же идёт и выбор инструментов для реализации, подбор используемых технологий и т.д. Ну и как бы в результате все остаются довольны.
Для обозначения *aaS на сколько я знаю есть термин — XaaS (Anything as a Service)
Хотелось бы технических подробностей, в особенности связанных с безопасностью MaaS.
Я бы сказал, что MaaS, как и любой другой XaaS не надо пихать куда попало.
MaaS можно запихнуть, например, в телевидение (как отрасль). Вы разворачиваете инфраструктуру мониторинга телеканалов в районе последней мили и продаёте её данные телеканалу/вещателю/рекламным агентствам/роскомнадзору/заинтересованным лицам. Сюда же можно приплести систему подсчёта рейтингов, если ставить оборудование в точку, где можно оценить не только качество сигнала, но и количество зрителей.
А вот сценарий мониторинга внутренней сети, кроме сферического в вакууме (применяем MaaS ради демонстрации применения MaaS), мне придумать сложно. Мониторинг «снаружи» — да. Например, арендуем дохлые сервера по всему миру и проверяем доступность сервисов из различных точек. И сразу можно выяснить, что наш сайт детского сада не был доступен из Гватемалы с 0:15 до 0:17 по гринвичу =)
Я бы с удовольствием поиграл в перезапуск Dungeon Keeper, именно первый и именно такой, какой он был, только с обновлённой графикой. Доработанные клоны как-то не торт =(
А ещё можно использовать софтовый видеомикшер vMix с обвязкой из тех же всеядных BlackMagic Intensity Pro. Дёшево и сердито. И может RTMP и множество других плюх.
По поводу свистков, всё зависит от того, где они будут стоять и сколько будет людей. У нас пару раз были проблемы при количестве народа в несколько тысяч в одном месте.
Мы в телевидении пользуемся специальным оборудованием для проведения прямых трансляций. Бывает стоечное исполнение, бывает мобильное. Как раз чтобы не задумывать о том, что где-то не будет интернета — он всегда с собой. А на такие короткие мероприятия можно и арендовать, а не покупать.
На входе понимают HD-SDI и HDMI. Я пользовался оборудованием AviWest и отечественным AirHD. Умеют стримить через любой RTMP сервер, YouTube, UStream и прочие.
Именно поэтому управленец, принимающий решения, должен быть в курсе того, как и что будет реализовано, чтобы не подставлять себя, свою команду и организацию.
А ещё надо учитывать, что каждый вышестоящий уровень уменьшает названное исполнителем время где-то процентов на 5-10.
Программист сказал, что сделает за неделю, руководитель отдела назвал 6,5 дней, координатор уже рассчитывает на 6 дней… Директору докладывают, что всё будет готово к утру, с чем и поздравляют исполнителя, который теперь уже вынужден работать ночами!
Руководитель/менеджер не хочет слышать «нет, невозможно», он обычно хочет видеть варианты (пусть даже укрупнённые), из которых он выбирает: хотите 5км вертикально? Нет проблем, за вертикальный асфальтоукладчик готов взяться Завод тяжелого машиностроения им.Кащенко, его создание займёт 10 лет, стоимость будет -надцать млрд, если всё ок — завтра приступаем, итого в 11 лет уложимся. А можем дёшево и сердито положить горизонтально, за неделю, ещё и в 8 раз больше.
Так и с ПО: получая задачу ты уже в голове (а лучше на листке) прикидываешь примерный объём работы, к концу совещания уже готов примерный план работ. Можно прикинуть сроки, лучше умножить на 2 или 3. Понятны задачи, что являются ключевыми, а на чём можно сэкономить и сделать после сдачи (а даже если не сделать — не критично).
Я одно время в одной интересной отрасли (не медицина, конечно, но попытка тоже даётся только одна) получал задачи класса «завтра едете туда-то, что делать — определяетесь на месте, задача должна быть выполнена». То, что нужна подготовка, предварительное обследование, планирование и прочее — никого не волнует… Две минуты на обдумывание, навскидку 2-3 возможных варианта исполнения, согласование одного из предложенных.
Партия сказала «Надо!», комсомол ответил «Есть!». Мотивируем сотрудников на выполнение невыполнимого. Приехали, обследовали, на месте принял/уточнил/согласовал решения, спланировали, развернулись, отработали, свернулись, уехали. Самое сложное для меня было так распределить и донести задачи, чтобы исполнители с ними справились. А самое страшное было то, что результат зависит ото всех: один накосячит — накроется работа всей команды. Но при этом я сам знаю всё, что должен сделать исполнитель и могу проверить/исправить его работу.
Но зато все довольны: и заказчик, и руководство, и непосредственные исполнители, т.к. выполнили «невыполнимое».
В этом был свой драйв =)
Вон, народ ставит ориентировочные сроки полёта на Марс, и стремится к ним! И даже если они просчитаются и отправятся на год позже — они всё равно отправятся на, мать его, Марс! А если сроки не ставить — работа не будет выполнена никогда.
Хуже того, на переговорах с заказчиком такой управленец уверен, что создать дополнительное поле в таблице — это работа на пол-года, а вот определить, например, что на картинке изображена машинка или котег — чё там думать, результат будет уже завтра, это же элементарно!
Может в бизнес-аналитики/тимлиды податься? Как раз работу ищу =)
Резюме: Быстро нахожу общий язык с людьми. Синхронно перевожу с языка заказчика на язык исполнителя и обратно. Умею понять заказчика и донести до него позицию исполнителя. Что не может сделать конечный исполнитель — сделаю вместе с ним, заодно обучу.
Сейчас ищу перспективную компанию/команду, где умения будут оплачены и востребованы, в идеале — в полном объёме… Переезд? Нет проблем, хоть завтра.
Я бы сказал, что знания лишними не бывают, неизвестно где и как они пригодятся. Есть возможность учить математику в общем и машинное обучение в частности — учи. Но и интересную работу никто не запрещает искать =)
Обрабатывать исключения, не давая обрушить систему — обязательно.
ИМХО, конечно.
Считаю, что «правильность» реакции зависит от конкретной ситуации, используемого языка, окружения и т.д.
Если мы говорим про обычное прикладное ПО, то от себя могу сказать, что считаю п.4 неправильным, если иное не оговорено ТЗ. Во всех остальных случаях исключительная ситуация должна быть обработана и, как минимум, не должна приводить к потере/искажению данных.
Элементарный пример — поле, в которое должна быть введена цифра, например, целочисленное поле «кол-во»… Очепятываемся и, в зависимости от кучи факторов, получаем от нефатальной ошибки, до фатального вылета без сохранения =(
У нас в крае такая милая программа для сдачи данных в ПФР ходила (или до сих пор ходит): одна очепятка и фатал эррор с потерей данных. Хотя, судя по внешним признакам, можно было бы хотя бы в блок try… обернуть
Мне как-то один исполнитель очень долго доказывал, что система оповещения по электронной почте (вставить в функцию логов несколько строк для отправки уведомления в случае появления критических ошибок) из Java-приложения — это титанический труд, который как минимум удвоит стоимость и учетверит объем работы. Пришлось немного процитировать RFC (если просто на сокетах писать), ну либо предложил воспользоваться имеющимся в Java классом. Исполнитель негодовал.
Часто исполнители нагло пользуются незнанием заказчика. Это не хорошо. При чём это касается не только нашей отрасли, менталитет у нас что-ли такой: кинь ближнего своего, ибо не ведает он…
Мне кажется, что статья описывает скорее работу кодера, но не программиста.
Это, считаю, как оценивать работу художника по количеству мазков или ставить над ним камеру и учитывать только время касания холста кистью. Ну и, конечно, не оплачивать те мазки, поверх которых были сделаны другие…
С другой стороны, очень часто наблюдаю ситуацию полнейшей незаинтересованности исполнителя в реализации проекта и, как следствие, попытки потом прикрываться сознательно плохо составленным ТЗ. А сколько раз я сталкивался (в роли эксперта при приёмке) с позицией исполнителя «в ТЗ ведь не прописано, что надо проверять входные данные на корректность...» — не счесть =)
Я всегда стараюсь сесть вместе с заказчиком и постараться вместе с ним разобраться, что же всё-таки нужно получить в итоге, расписываются плюсы и минусы на перспективу и т.д. Вот тогда идёт работа на результат. Тогда же идёт и выбор инструментов для реализации, подбор используемых технологий и т.д. Ну и как бы в результате все остаются довольны.
Хотелось бы технических подробностей, в особенности связанных с безопасностью MaaS.
Я бы сказал, что MaaS, как и любой другой XaaS не надо пихать куда попало.
MaaS можно запихнуть, например, в телевидение (как отрасль). Вы разворачиваете инфраструктуру мониторинга телеканалов в районе последней мили и продаёте её данные телеканалу/вещателю/рекламным агентствам/роскомнадзору/заинтересованным лицам. Сюда же можно приплести систему подсчёта рейтингов, если ставить оборудование в точку, где можно оценить не только качество сигнала, но и количество зрителей.
А вот сценарий мониторинга внутренней сети, кроме сферического в вакууме (применяем MaaS ради демонстрации применения MaaS), мне придумать сложно. Мониторинг «снаружи» — да. Например, арендуем дохлые сервера по всему миру и проверяем доступность сервисов из различных точек. И сразу можно выяснить, что наш сайт детского сада не был доступен из Гватемалы с 0:15 до 0:17 по гринвичу =)
Может быть есть ещё единомышленники? =)
По поводу свистков, всё зависит от того, где они будут стоять и сколько будет людей. У нас пару раз были проблемы при количестве народа в несколько тысяч в одном месте.
На входе понимают HD-SDI и HDMI. Я пользовался оборудованием AviWest и отечественным AirHD. Умеют стримить через любой RTMP сервер, YouTube, UStream и прочие.