Pull to refresh

Comments 67

Комментируем! Создал «первый коммент», чтоб можно было комментить, пока Хабру не починят :) Подробности: habrahabr.ru/qa/12275/
Пятничные сиськи в понедельник? :)
Ну а как еще завлечь читателей к данной статье?
После того как начал читать статью и забыл что в начале нее сиськи =))
Спасибо что напомнили — вернулся в начало =))
Лучше бы этой фотки не было. Кроме сожаления не вызывает ничего.
А текст сильно обнадёживает?
На своем опыте столкнулся сейчас с подобной задачей. Решением руководства было отправить меня в командировку, чтобы на месте сразу разобраться с самой причиной задачи, понять зачем она и для чего. И уже после этого я понял, что шел совсем не тем путем, и поэтому ничего не получалось
В моем жизненном опыте в подобных ситуациях развивалась «ударная волна первого типа». К сожалению это очень сказалось на моем душевном состоянии и соответственно на работоспособности. Но, время лечит.
Напомнило
А можно конкретный пример? А то за всю свою карьеру ниразу с нерешаемым не сталкивался. Есть реально трудные задачи, есть даже задачи у которых нет точного решения, но и они имеют приближенные решения подходящие для конкретного случая.
Иногда невозможность обусловлена необходимостью вписаться в бюджет. Например, Вы легко реализуете некий алгоритм на 16 Кб памяти, но в используемом девайсе её только 8.

Еще бывает невозможность вписаться в сроки — видели на сайте госзаказов объявления типа «медецинский портал, истории болезней, карточки, врачи… бла-бла-бла» — сделать за 12 дней.

Иногда невозможность вызвана идиотизмом начальства: «у меня телефон с Wi-Fi, а если посреди леса интернет не ловится, значит Wi-Fi сломан — чините!»

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

Ну и т.д.
Во первых давайте все таки считать что мы работаем с адекватными людьми, которые возможно не владеют терминами, но понимают вещи когда им что то обьясняешь.
А что касасется ваших примеров:
> Иногда невозможность обусловлена необходимостью вписаться в бюджет. Например, Вы легко реализуете некий алгоритм на 16 Кб памяти, но в используемом девайсе её только 8.

А вы попробуйте не использовать ООП.

> Еще бывает невозможность вписаться в сроки — видели на сайте госзаказов объявления типа «медецинский портал, истории болезней, карточки, врачи… бла-бла-бла» — сделать за 12 дней.

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

> Иногда невозможность вызвана идиотизмом начальства: «у меня телефон с Wi-Fi, а если посреди леса интернет не ловится, значит Wi-Fi сломан — чините!»

Такое случается, но обычо в этом случае под словами Wi-Fi имеют ввиду доступ к интернету. Ну расскажите человеку как подключиться через оператора.

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

Это решаемая задача, хотя и трудная. Например «любую капчу» можно заменить на капчу нотами и пусть юзер ноты напевает, тогда можно и без тренировки распознавателя. А еще можно тренировку распознавателя включать каждый раз когда человек проговаривает капчу а капчу сделать состоящую из нескольких слов, причем количество используемых слов ограничить например десятью. Можно даже первый раз ему все эти слова показать ;)

У Вас хороший оптимистический взгляд на жизнь, Вы верите, что можно всегда работать с адекватными людьми и Вам, я так думаю, никогда не обламывали крылья в верхней точке полёта. Я желаю Вам и дальше сохранить это мировозрение и ради этого готов даже признаться, что всё написанное в статье — полная чушь и Вы правы — невозможных задач нет. Снимаю шляпу.
Спасибо. А что касается работы с адекватными людьми, то с неадекватными просто не нужно работать, из этого все равно ничего не выйдет )
Однако с ними работают, и неплохо с этого зарабатывают.
Хотя это уже вопрос психологии.
> Например «любую капчу» можно заменить на капчу нотами и пусть юзер ноты напевает, тогда можно и без тренировки распознавателя

Капча и распознавание без тренировки — это было два разных примера, как я лично понял, а вы их слили в одну задачу ;)
Вы правы. У меня не было целью показать как решать эти задачи, а только указать на то, что все задачи решаемы. А если бы вы немного подумали прежде чем минусовать мне в карму, то поняли бы что подход применимый для распознования голосовой капчи подойдет и для распознавания без тренировки.
С чего вы решили что я вас минусую? Я просто заметил вам что вы неправильно поняли коммент: решь шла о таких нерешаемых задачах как распознавание любой капчи и управление голосом. Причем тут голосовое прохождение капчи я не понял и написал вам об этом
Это я Вас минусую :)

Вам привели нормальные жизненные примеры, а Вы написали «А вы попробуйте не использовать ООП». Если Вы хотели привести шутливые ответы, то Ваш юмор слишком тонок для меня. Если же это было всерьез — минусы оправданы.
К слову, использование ООП вместо процедурного далеко не всегда влияет на результат работы компилятора.
Мне безразлична моя карма на хабре, но вы говорите вещи в которых не понимаете, а то что вы минусуете, говорит только о вашем апломбе не имеющем никакого бэкграунда.

Судя по вашему «высеру» (по другому не скажешь),
Вы скорее всего никогда не занимались эмбед программированием и скорее всего даже не предполагаете как можно программировать в «обьектном стиле» на обычном C используя связанные списки, если конечно вообще понимаете что такое связанный список.
>> Иногда невозможность обусловлена необходимостью вписаться в бюджет. Например, Вы легко реализуете некий алгоритм на 16 Кб памяти, но в используемом девайсе её только 8.

>А вы попробуйте не использовать ООП.


История одного байта
UFO just landed and posted this here
к сожалению, когда идешь по улице не вседа смотришь под ноги.
особенно на ярко освещенных центральных городских улицах.
но иногда и там собак выгуливают и лошади бродют.

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

вот как потом в рабочее состояние приходить, вот вопрос интересный.
потому как восстанавливаться после таких неприятностей приходится.
Мои пять копеек. Мне была поставлена серьёзная по объёму и сложности задача. Работающий прототип мне удалось сделать своими силами (мне немного помогал советами более опытный коллега). Однако, когда мной руководителю был представлен на суд черновой вариант, он сказал, что «очень сыро» и надо дорабатывать. Затем был составлен список крупных и сложных задач, хотя он и не был особо длинным. Вновь закипела работа. Когда через пять недель меня спросили о прогрессе, я дал отчёт, и шеф «присел»: «почему так долго-то?!». Дальше я и мой коллега объяснили, какие проблемы у нас занимают много времени и почему; какие проблемы мы считаем сложными и прогнозируем большие затраты времени. Шеф понял, что дело плохо. Дальше он связался с заказчиком (наша контора выполняла работы по договору подряда) и объяснил ситуацию. Разработку подсистемы быстро свернули как экономически невыгодную.

P.S. Я был тогда совсем нубом, поэтому допустил большой факап с тем, что не сообщал о прогрессе шефу сам. С другой стороны, он тоже мог проснуться чуть пораньше, особенно учитывая, что он — один из двух сооснователей софтверной-таки фирмы.
вот чтобы не было таких ситуаций, нужно докладывать начальнику о прогрессе. Хоть раз в неделю, хоть каждый день — в зависимости от. Когда начальник будет знать о всех проблемах, он сможет вовремя решить продолжать вам биться над задачей, или нуеенафиг если перспективы неясны.
Если Вы говорили мне, то я согласен. В качестве оправданий: а) я был нубом и не понимал, что совершаю ошибку, не сообщая о сроках; б) шеф не был нубом и, зная, что я новичок, мог бы держать руку на пульсе.
не, я в первый ответ ответил =) У меня хабр еще плющится — не могу каментить топик сам по себе =)
Сорри, значит я неправильно понял. :)
сколько раз наблюдал — когда приходит время расплаты начальники предпочитают забыть о теории и просят попедалить основательно, забить на процессы, добавить новичков в последний день проекта не взирая ни на каких Макконнелов и же с ними.

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

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

а если надо выбирать из двух задач я выберу ту что посложнее, пусть может там и жопа встретится.
зато потом будет что вспомнить
У нас с этим все просто — надо оценить время выполнения задачи — если 25 лет в общем виде, то можно договорится с менеджером и сделать частное решение за адекватное время. Если просто так сложно оценить задачу — надо ставить себе задачу на оценку задачи (и ее тоже оценивать во времени). во время оценки становится примерно понятно, что надо делать для решения задачи, время, необходимое для разных путей решения. Тайм менеджмент наше все.
а если оценка задачи сама по себе ресурсоемкая штука и может потянуть на отдельный проект а контракт уже за вас подписали?
да в нем еще и стоимость и объем работ и этапы с датами проставили.
то здесь есть два пути развития: либо оценку сделал компетентный специалист, и тогда вы с ней соглашаетесь, либо вы ищите работу, на которой начальство, либо компетентно, либо адекватно до той степени, что-бы советоваться с техническим специалистом, для установки сроков на выполнения задач.
завидую я вам, все у вас просто — черное, белое все на своих местах
я себе иногда тоже завидую)
Просто у меня на работе задачу всегда оценивает исполнитель.
Я же не про черное и белое написал. Если вам не нравится работа — меняйте ее. И не ищите отговорок для того что бы держаться за место.
да я вроде и не жаловался.

в большой компании где пишут под заказ чаще все по другому.
хотя я больше в таких и не работаю… но:
пресейл — контракт — работа
и первое с третьим может совсем быть не связано
и вы можете сколько угодно ругать пресейл но они задачу выполнили.
дальше задача реализовать проект с прибылью и чтобы заказчик остался доволен.
это смысл такого бизнеса.

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

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

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

а что если нет у вас еще экспертизы в нужной области?
а может и вообще область новая?
и откуда такая уверенность что умножив на два у вас все получится?

а как же COCOMO, FP или хотя бы Story Points
то о чем вы говорите применимо для маленьких проектов

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

А зачем вы все эти вопросы мне задаете? Вы хотите от меня универсальный ответ? Его нет.
Про уверенность умножения на два я вообще не понял. Это моя субъективная оценка действительности. Я самый пессимистичный на мой взгляд прогноз умножаю на два, что бы не недозаложиться. А руководитель проекта мою цифру умножит еще на два.

Я все упрощаю специально. Молодого специалиста на километр не подпустят к управлению транснациональной корпорацией. Даже к средней не подпустят. Максимум дадут посмотреть, как это делается. Тогда ему мои советы не нужны. А вот если он сам решил делать что-то, то это будет маленький проект, по началу. И тут вы уже писали, что то, о чем я говорю применимо как раз для малых проектов.
не говорите о сложных вещах что они простые и не путайте термины.
так моя мысль выглядит понятнее?
Топик «режет по живому». Сталкивался с подобным, конечно были не невозможные задачи, а просто слишком трудные для меня, переоценка своих сил и возможостей. После таких вот провалов еще несколько месяцев ходишь как вареный. И что самое неприятное, что это ни чему не учит.
Ну из последнего, хотя это и не связано с работой. Один хороший знакомый и по совместительству бывший работодатель как-то написал с простеньким вопросом по mysql, я ему ответил. Потом он спросил могу ли я ему помочь с дипломом для его сестры, ну я под словом «помочь» понял по-своему, да и отказывать не умею и согласился. Оказалось, что помочь — это сделать самому практическую часть в кратчайшие сроки, отказывать было уже поздно и я стал вгрызаться. Надо заметить, что сам проект был не трудный, но оказался не по моим плечам, да еще и чужой код. В общем ничего у меня не получилось, мне никто конечно же не упрекнул, но было стыдно и самооценка с мотивацией пропали надолго.
Мне однажды поставили невозможную задачу. Причём так, что ставящий её не вполне понимал глубины задачи, и думал что она проста. Я сказал, что это невозможно. На что мне ответили что у меня есть время и зарплата, которая никак не зависит от результата. Я начал решать её, чтобы докопать до места, где я однозначно покажу и докажу что её решить нельзя. И такого места не нашлось, задача была решена. Я видел одно подобное решение, однако оно не затрагивает некоторых глубоких моментов. В целом в российском и англоязычном интернете проблема считается нерешаемой. После этого я понял что этот метод (искать явное противоречие у которого можно будет ткнуть пальцем и сказать — тут нерешаемо) очень хорош, т.к. обычно такой момент отсутствует. Также я знаю что необычайный оптимизм руководителя может очень сильно повлиять на результативность работы работника. Сам бы я списал задачу в утиль с пометкой: «невозможно».
На эту тему нравится аналогия В.К.Тарасова в книге «Искусство управленческой борьбы»:
К примеру, если попросить человека шагнуть по лестнице на одну ступеньку вверх 100 раз – вероятность успеха 98%, если шагнуть через ступеньку – 95%, через две ступеньки – 15%. Чуть усложнили задачу — и резкий обрыв вероятности успеха.
У каждого человека есть своя «область ближайшего развития» — то, что пока не делал, но если попробует — наверняка получится. На нее можно рассчитывать, но её нужно также и учитывать.
Кстати, очень интересный метод — от противного, вместо поисков открытых дверей, пытаться ломиться в закрытые, в которые еще никто не заходил :)
Да отличный, я только совсем недавно выявил его в такой простой и чистой формулировке. Обычно когда я упираюсь в стену и становится невозможно от сложности, я сажусь и начинаю в блокноте писать пост на тематический форум, в нём описываю задачу и все пути решения какие я предпринял. И тут же пытаюсь заранее предсказать всё, что мне могут написать в ответ и отвечаю на это, что мол дело гиблое и там лазил и сям, и опять отвечаю сам себе и себя опровергаю, когда получается месиво килобайт на 20-30 я обычно нахожу выход. Эта писанина удаляется и проблема решена.
Ага, ситуация «пока писал — сам все понял» очень типична на тематических форумах, думаю все бывали в похожей ситуации
Я таким же образом писал в Q&A несколько раз. Не дописал :)
А я как раз пару недель назад писал в Q&A и «дописал». Правда уже на момент написания решил «обойти» проблему, а не решать частно, но вопрос оставил, на случай «а вдруг!», как в фильме «Восход Меркурия» — последняя проверка так сказать, чтобы оправдать сделку с совестью)
как говорил Эйнштейн «Все с детства знают, что то-то и то-то невозможно. Но всегда находится невежда, который этого не знает. Он-то и делает открытие» собственно:)
Я не могу решить эту задачу, наверно я очень глуп.
Я не могу решить эту задачу, потому что это невозможно.
Я не могу решить эту задачу, но и все эти великие люди тоже не могу.

Отсюда. С 38 минуты. www.lektorium.tv/lecture/?id=13384
Есть одна реально невозможная задача, не считая тех задач, которые противоречат законам термодинамики — это задача сделать «Что-то, но не знаю точно, что». Один раз столкнулся с таким: вначале требования были одни, ну пилим, пилим, прототип какой-то показали, потом возникают просьбы «а вот я посмотрел, что нужно сделать вот так а не так, я хотел вот так вот»… матерюсь, переделываю первый кусок, потом аналогичный разговор, дальше переделываю прогу, потом… короче забиваю нахрен на архитектуру пилю как попало, делаю «босс билды» и так далее. Ну в общем через пару месяцев такого кайфа окончательно дохожу до точки, начинаю откровенно страдать херней и искать новую работу… Так проект и умер, хотя будь четкое ТЗ в самом начале с четким планом, то родился бы четкий проект. Но я был еще совсем зеленым и ввязался просто так. В процессе выяснилось, что до меня еще раза два пытались запилить этот проект и все разы он с треском проваливался.
К счастью, на самооценку этот фейл никак не повлиял. Но поругался я под конец с начальством знатно!
А у меня от подобной невозможной задачи остался положительный опыт. Когда-то лет 5 назад (когда я еще ничего не знал) решил я податься в сторону фриланса и попался мне проект, на первый взгляд не очень сложный. Надо было подсчитать на видео количество людей, которые куда-то ходят (то ли дорогу они переходили, то ли еще что-то). И все бы ничего, но хотелось >95% точности при любых условиях (деревья на ветру, транспорт, толпы людей)… Это сейчас я уже знаю, что такое любые условия и 95% точности, а тогда верил в сказку… В общем помучался я месяца 3, даже получил какие-то результаты вполне приличные, но не для любых условий конечно, денег само собой не получил, ибо проект не выполнен, но за то время узнал много много всего нового и интересного, а под конец еще и пришло приглашение от одной фирмы работать на них. Так что нереальные задачи — это не всегда плохо, особенно для студентов:)
Да и сейчас занимаюсь нереальной задачей, но уже совсем другая история… Как показывает практика, в процессе решения нереальных задач могут появляться хороше решения реальных.
А можно примеры таких невозможных задач?
Как по мне — любая задача имеет решение. И не обязательно техническое. Грамотно объяснить почему «невозможно» — тоже решение. Причем, тут лучше «при первых признаках опасности» сообщить об этом. То есть, этапа «ну может быть что-нибудь все-таки придумаешь?» в принципе не должно бы быть.

Впрочем, YMMV :)
Согласен с предыдущим комментом, в описанной схеме явно баг во взаимодействии разработки с бизнесом. Решая подобную задачу вы точно должны знать как это выглядит с той стороны и заказчик должен быть в курсе прогресса, чтоб по необходимости допиливать требования к задаче по ходу.
Конечно я говорю только о настоящих невозможных задачах, «невозможных» с технической точки зрения, ситуация сделай то, не знаю, что за 10 дней о другом.
Ох, отличный пост, вчера вечером сидел за такой задачей, уже больше дней 5 в сумме с овертаймом и выходными. А решения все не было и не было. Знакомые ощущения, но мне повезло — руководитель хорошо знаком с моей предметной областью, после разговора немного поразмышляли, в итоге решили, что это очень второстепенно и нужно забивать, закрыли задачу где то процентов на 80, а оставшиеся 20% из-за которых весь овертайм того не стоят. :)
Было такое. Пришли заказчики договорились о деньгах сроках и прочем. Задача с виду совсем плевая что называется на размяться. Тяп-ляп. Основной функционал готов. Тестим. Медленно. Очень медленно. Операция которая должна занимать полсекунды — секунду, ну три, ну пять, ну десять секунд!!! Занимает до… 15 минут. Занавес.

Переписываем вывод. Медленно. Отказываемся от SQLite — из-за тормознутости (забавно правда ?), пишем свою «БД» — все равно медленно. Пробуем десятки различных вариантов. Самый быстрый укладывается в минуту. Но при этом вывода можно сказать что нет.

Вместо двух недель убито 2 месяца результата нет. Заказчики на взводе. Я в неиллюзорной депрессии.
Заказчики в итоге куда то пропадают. Еще неделю пытаюсь вяло допинать задачу. Бестолку. Хотя еще 10 секунд отыграл. Неприятным камнем остается данный заказ.

Через месяца 3 на меня лично выходят заказчики и спрашивают: «А может ну все таки ну если еще чуть чуть..». Матерюсь. Сильно матерюсь, но соглашаюсь. Еще два месяца не дали каких либо вменяемых результатов. Приехали. Все версии и наработки отдал. И иногда когда настроение портиться особенно сильно я достаю эту задачу и штурмую ее как неприступную крепость. Пока безрезультатно.

Проект так никто и не реализовал заказчикам. Хотя после меня пыталось около 5 компаний решить данный вопрос.
Была у меня одна сложная задача, которую я решил процентов на 95%.
Делал долго — почти год. Сдавал этапы.
Уложился с запасом в требования по использованию памяти и процессора и времени работы задачи.
Потом оказалось, что для решения этой задачи амер. заказчики искали коммерческую библиотеку за «любые» деньги — не нашли, в течении 3 лет давали на решение двум местным софтверным компаниям — не решили. Потом вот отдали русском фрилансу :)
5 не решенных процентов — это один самый сложный (и невероятный) случай из представленных сценариев, так что заказчик решил, что может жить без него.
Несмотря на затянутый срок по сравнению с утвержденным начально, заказчик выплатил еще и премию.
Дьявольски интересно знать, что это за задача такая.
да нет проблем, задача «простая»:
на C# или C++ написать сборку или библиотеку для вывода таблицы в PDF.
дьявол в деталях:
— таблица содержит несолько тысяч столбцов и десятки тысяч строк
— colspan и rowspan — объединение строк и столбцов
— подтаблицы — таблица внутри ячеек(объединных ячеек)
— индивидуальные шрифты / цвета/ стили для любой ячейки/строки/столбца
— строки с промежуточными итогами
— повторение заголовков / подвалов на каждой странице
— разбиение на страницы по выбору слева-направо/сверху-вниз или сверху-вниз/слева-направо
т.к. это pdf будет генериться на лету на сервере, то время генерации не должно превышать N мин, сервер был какой-то четырех ядерный (2ГГц давно это было), уложиться в память
— размер файла тоже был ограничен

Проблема N1 — все доступные библиотеки оперируют загрузив данные целиком в память. А это в нашем случае 1000 столбцов х 10000 строк = 10M ячеек минимум(!). И каждая может иметь контент, атрибуты и размер непонятен пока ты не получил последнюю строчку. Вообще отрисовка таблиц — больное место во всех браузерах и табличных программах. И разработчики годами ее вылизывают.
У меня не было такого сервера, поэтому результирующий код укладывался в требования работая на селероне 900МГц, с гигабайтом памяти :)
вот у меня сейчас замечательная ситуация:
проект идет один год
пишут его два программера — гуру супермозга, кучу проектов сделали
вышел один релиз который показал что проект сырой:
— все время новые баги лезут.
— локализовывать их сложно
— окружение быстро меняется и повторить ошибку по логам практически невозможно
сейлзы отказываются его дальше продавать.

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

вот не знаю что лучше — тупо баги фиксить или пойти начальника программировать…
Sign up to leave a comment.

Articles