Здравствуйте, trial, Вы писали:

T>Здравствуйте, GlebZ, Вы писали:

GZ>>Проясню, вчера не было времени дописать.
GZ>>1. Возьму пример из жизни. При ошибке коннекта через DCOM, пользователю выводится ошибка: "Произошла системная ошибка в процедуре CoCreateInstanceEx". Для любого программиста, это вполне достаточная и главное понятная информация. Однако приходит тестировщик, и говорит что это является ошибкой. Для него, как для пользователя, данная информация не понятна. Программист возражает: "А если я выведу другую ошибку, то я не пойму что произошло". Безусловно, что в данном случае, тестировщик прав, потому что он оценивает ситуацию со стороны потребителя. Это наиболее явный пример.

T>Тестировщик то прав, но, среди достаточно опытных программеров (по крайней мере в моей текущей команде), я не видел людей, которые бы подобное сообщение сами не сочли ошибкой. Так что ИМХО несколько высосано из пальца.
Это просто самый показательный пример. Другой пример, использовал одну библиотеку к девайсу. Нашел ошибку. Звоню производителю. Отвечает программист. Ответ был такой: "Это не бага, а особенности Windows". После чего, объяснил в чем была особенность при работе через USB и почему библиотека выдает ошибку. Меня, как пользователя данной библиотеки, было сильно наплевать на особенности работы USB. И тестировщику, я думаю тоже.

GZ>>2. Тестировщик ничего не знает об архитектуре. На моей практике, ошибку выдавало даже переименование окна в ресурсах. Программист, так как знает, что это не должно выдавать ошибку, даже проверять не станет. Для тестировщика эту информацию всегда нужно проверять.

T>Если есть тест-план — то проверит в лучшем виде.
Да по указанному в пункте 2 причинам, программист и не вставит данный пункт в тест-план, и не будет сообщать о изменении данной функциональности. Я могу вспомнить до фига случаев, когда простые изменения перед релизом, без согласования, приводили к плачевному результату. С точки зрения программиста некоторое изменение может ему показаться простым. А если продукт делали десятки программистов, то такие изменения (даже внутри опубликованного интерфейса), может привести к плачевным результатам. И в данном случае тестировщик, который даже и не догадывается о внутренней архитектуре программы, незаменим. Ему главное, чтобы все работало. А как его уже мало волнует да и не надо ему знать. И именно поэтому, готовность релиза определяет именно тестировщик а не программист.
В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
Хотя в этом виноваты оба.

IMHO Все вышеперечисленное, естественно, не касается автоматизированного тестирования и стиля XP.
С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Это просто самый показательный пример. Другой пример, использовал одну библиотеку к девайсу. Нашел ошибку. Звоню производителю. Отвечает программист. Ответ был такой: "Это не бага, а особенности Windows". После чего, объяснил в чем была особенность при работе через USB и почему библиотека выдает ошибку. Меня, как пользователя данной библиотеки, было сильно наплевать на особенности работы USB. И тестировщику, я думаю тоже.

Ну...Это просто плохое воспитание программиста, так что опять не согласен. У меня в команде такого быть не может. Тем, с кем я работал как со стажёрами — я сразу воспитывал в таком плане. Остальные это как-то и сами понимают.

T>>Если есть тест-план — то проверит в лучшем виде.
GZ>Да по указанному в пункте 2 причинам, программист и не вставит данный пункт в тест-план, и не будет сообщать о изменении данной функциональности.

А вот тест-план пишет не программист, а его тим-лидер. Так что снова не согласен.

GZ>В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
GZ>Хотя в этом виноваты оба.

Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

Здравствуйте, trial, Вы писали:


T>А вот тест-план пишет не программист, а его тим-лидер. Так что снова не согласен.

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

GZ>>В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
GZ>>Хотя в этом виноваты оба.

T>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

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

Здравствуйте, byur, Вы писали:

B>Здравствуйте, trial, Вы писали:



T>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

B>Вау ... прогаммера несчастного давят сроками, требуют чтобы он еще и архитектуру продумал, и еще и требуют чтобы он при этом не допускал дефектов ... "вы что, не можете писать без ошибок?"

Очевидно, уважаемой trial работает небольшой группой, в которой все административные функции и ответсвенность лежит на одном team-leader.

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

С уважением, Gleb.

Здравствуйте, byur, Вы писали:

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

Про тест-аналитика: и часто встречается такая должность? Я вот не видел. Может в идеале оно так и должно быть, но мы то живём в далеко не идеальном мире. Поэтому тут тест-план будет писать тимлидер (тестеров, а не программистов). Или сам тестер...А тест-аналитик...Это что-то из области фантастики.
А если получается так, что тестировать приходится силами программистов — то соответствено тимлидер программистов.
Больше, увы, некому. Се ля ви.
Про тимлидера: он, прежде всего, должен отвечать за то, что бы его команда работала. Работала хорошо и делала то, что надо. Надо код писать — значит он должен сделать так, что бы его люди писали код. Надо тестировать — должны тестировать. Надо мыть полы — он должен найти способ мотивировать их мыть полы. В кратчайшие сроки и с наилучшим качеством. Если уж подходить формально — то он как раз не должен заниматься продумыванием технических решений — для этого есть архитектор. Вот только в нашем неидеальном (зато настоящем!) мире — это часто один и тот же человек (не везде конечно, но часто).

GZ>>>В этом правда, есть свои плюсы. За багнутую программу ставят именно тестировщика, а не программиста.
GZ>>>Хотя в этом виноваты оба.
T>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

B>Вау ... прогаммера несчастного давят сроками, требуют чтобы он еще и архитектуру продумал, и еще и требуют чтобы он при этом не допускал дефектов ... "вы что, не можете писать без ошибок?"

Требуют, что бы он допускал миниму дефектов. Это, кстати, тоже работа тима, во многом. Я кстати, не совсем правильно сказал. Сначала нагнут тима, а потом — если он сам сочтёт нужным — то он нагнёт программера.

Правда, я не совсем корректно выразился, наверное. Я имел ввиду — рабочее тестирование. Тогда — виноват программер. Если после выпуска — то, конечно, доля вины тестера большАя (тут уже, я затруднюсь сказать, кто виноват больше). Зачастую, в самом деле тестер.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, byur, Вы писали:


GZ>Очевидно, уважаемой trial работает небольшой группой, в которой все административные функции и ответсвенность лежит на одном team-leader.

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

GZ>То что, надо ставить именно тестировщика, вопрос как-бы не подлежит обсуждению. Ключевое решение лежит на PM и на группе тестирования.(правда, иногда только в идеале, есть начальники и повыше). Прямая обязанность тестировщика выявить все баги (или их максимум).

Во-во. С этим я не в коем разе не спорю. А прямая обязанность программиста — наплодить как можно меньше багов.

GZ>Однако вопрос, а надо ли при этом программиста обрабатывать?(безусловно, если это не криминальный случай, и он производит софт а не набор ошибок).

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

Я то под "нагнут" имею ввиду — "будут считать виновным" — а из этого вовсе не следует, что его уволят или лишат премии.

Здравствуйте, trial, Вы писали:

T>Здравствуйте, byur, Вы писали:

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

T>Про тест-аналитика: и часто встречается такая должность? Я вот не видел. Может в идеале оно так и должно быть, но мы то живём в далеко не идеальном мире. Поэтому тут тест-план будет писать тимлидер (тестеров, а не программистов). Или сам тестер...А тест-аналитик...Это что-то из области фантастики.
T>А если получается так, что тестировать приходится силами программистов — то соответствено тимлидер программистов.

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

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


T>Больше, увы, некому. Се ля ви.
T>Про тимлидера: он, прежде всего, должен отвечать за то, что бы его команда работала. Работала хорошо и делала то, что надо. Надо код писать — значит он должен сделать так, что бы его люди писали код. Надо тестировать — должны тестировать. Надо мыть полы — он должен найти способ мотивировать их мыть полы. В кратчайшие сроки и с наилучшим качеством. Если уж подходить формально — то он как раз не должен заниматься продумыванием технических решений — для этого есть архитектор. Вот только в нашем неидеальном (зато настоящем!) мире — это часто один и тот же человек (не везде конечно, но часто).

У каждого свой "настоящий" мир ... лично мне описанный мир не очень. В данном случае тимлидер подменяет собой менеджера. Насчет обязанностей архитектора ... то есть таки смысл почитать RUP и прочия, чтобы понять, что должен делать архитектор. А задача разработчика (и тимлидеоа в первую очередь) -- как раз технические решения -- оптимизация по скорости, памяти (если есть такая необходимость) ... какие библиотеки и/или фреймворки использовать, как добиться повторного использования кода, следить за версионированием кода, стандартами форматирования/представления .... Это отнюдь не задача архитектора или обычного разработчика ...

T>>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!

Согласитесь, вы это еще не весь "мир". Везде по-разному.


T>Правда, я не совсем корректно выразился, наверное. Я имел ввиду — рабочее тестирование. Тогда — виноват программер. Если после выпуска — то, конечно, доля вины тестера большАя (тут уже, я затруднюсь сказать, кто виноват больше). Зачастую, в самом деле тестер.

Да, похоже вы используете термины, которые мне не понятны. Что такое "рабочее тестирование"? Разработчики могут делать юнит-тестирование ... могут проверить работает ли формочка ...
Если у конторы нет денег на тестировщиков -- то нужно договариваться с заказчиками, чтобы они проводят тестирование, в т.ч. и приемочное ... Обычно для малобюджетных проектов это нормальная практика.

Здравствуйте, byur, Вы писали:

B>Идеальность тут не причем. Вариант первый -- если маленькая контора, и ее менеджмент не в состянии решать проблему дефектов софта в силу того, что "лежит под заказчиком с широко раскинутыми ногами", а руководство конторы не имеет планов на будущее и использует контору как возможность заработка первоначального капитала -- а там как кривая выведет . То скорее всего в этом случеа будет наблюдаться "соковыжималка" разработчиков. И видимо именно разработчики будут выспрашивать заказчика "что спрограммировать-то?" и заказчик будет им звонить непосредственно и говорить что нужно доваять, скорее всего у конторы то и скретаря нет. И это не вина разработчика, что он так попал ... а скорее беда. И руководство такой конторы будет вести разговоры, про то что в России "буржуйские" технологии не приживаются, что "они все это 100 раз пробовали", что "русский программист и кашу из топора сварит ..." ... и т.п.

К чему этот весь текст и какое он имеет отношение к нашему обсуждения — я не понимаю.

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

Так....и что?

B>У каждого свой "настоящий" мир ... лично мне описанный мир не очень. В данном случае тимлидер подменяет собой менеджера.

А вот это совсем мимо. Если проект крупный (мой случай) — то у менеджера в подчинении несколько тимов — каждый из которых отвечает за свою команду.

B>Насчет обязанностей архитектора ... то есть таки смысл почитать RUP и прочия, чтобы понять, что должен делать архитектор. А задача разработчика (и тимлидеоа в первую очередь) -- как раз технические решения -- оптимизация по скорости, памяти (если есть такая необходимость) ... какие библиотеки и/или фреймворки использовать, как добиться повторного использования кода, следить за версионированием кода, стандартами форматирования/представления .... Это отнюдь не задача архитектора или обычного разработчика ...

Сорри, я твой предыдущий посте не внимательно прочитал. Почему то решил, что ты под техническими решениями архитектуру имеешь ввиду

T>>>>Ну фиг знает. Где как, наверное. У нас — ставят именно программера, в первую очередь. Так что снова не согласен!
B>Согласитесь, вы это еще не весь "мир". Везде по-разному.

То, что я весь мир — я точно не говорил!

T>>Правда, я не совсем корректно выразился, наверное. Я имел ввиду — рабочее тестирование. Тогда — виноват программер. Если после выпуска — то, конечно, доля вины тестера большАя (тут уже, я затруднюсь сказать, кто виноват больше). Зачастую, в самом деле тестер.
B>Да, похоже вы используете термины, которые мне не понятны. Что такое "рабочее тестирование"? Разработчики могут делать юнит-тестирование ... могут проверить работает ли формочка ...

Тут вообще речь не про разработчиков -а про тестеров. Под рабочим тестированием я имею ввиду тестирование _до_ выпуска продукта. Ещё бывает после выпуска — это фидбеки

B>Если у конторы нет денег на тестировщиков -- то нужно договариваться с заказчиками, чтобы они проводят тестирование, в т.ч. и приемочное ... Обычно для малобюджетных проектов это нормальная практика.

Брррр.....Ну мы совсем куда то не туда зашли. Конкретно у нашего проекта тестеры есть. Около 10 человек. У всех остальных 20ти проектов в нашей конторе они тоже есть. Такое ощущение, что мы о разных вещах говорим.

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

Здравствуйте, trial, Вы писали:

S>>Примером может служить плохое сочетание программиста-кодера и тестировщика.
T>Не знаю, что говорит теория, и где берутся такие примеры, но вот практика показывает, что такое сочетание далеко не всегда плохое.

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

Здравствуйте, cvoronin, Вы писали:

C>Однозначно можно сказать, что весьма необходимая роль в проекте — администратор. Дабы не отвлекать разработчиков/программеров на написание бумаг, отчетов и прочей ерунды, нужной только начальству.

Т.е. по факту человек подделывающий проектную документацию. Замечательно...

По факту проектная документация нужна не чтобы ее "писать" — никто не хочет ее писать.
А чтобы ее использовать(это хотят все и ради это некоторые даже готовы ее писать).
Поэтому write-only документация бесполезна, а для начальства даже вредна.

A>Т.е. по факту человек подделывающий проектную документацию. Замечательно...

A>По факту проектная документация нужна не чтобы ее "писать" — никто не хочет ее писать.
A>А чтобы ее использовать(это хотят все и ради это некоторые даже готовы ее писать).
A>Поэтому write-only документация бесполезна, а для начальства даже вредна.

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

Здравствуйте, cvoronin, Вы писали:

A>>Т.е. по факту человек подделывающий проектную документацию. Замечательно...

A>>По факту проектная документация нужна не чтобы ее "писать" — никто не хочет ее писать.
A>>А чтобы ее использовать(это хотят все и ради это некоторые даже готовы ее писать).
A>>Поэтому write-only документация бесполезна, а для начальства даже вредна.

C>Кто работал в гос. конторе — тот поймет, сколько мусороподобной бумаги приходится оформлять — абсолютно не имеющей отношения к проекту. Например, "Разрешение на эксплуатацию электрического прибора" — дабы поставить чайник, кучу бумаг чтобы заказать расходники и проч.
C>Вот это имелось в виду...

Помоему проще не работать в гос конторах.

Здравствуйте, speedballer, Вы писали:


S>Хороший же тестировщик ни в какие программисты не рвётся, его амбиции распространяются на должности менеджера по качеству и директора по качеству.

объясните пожалуйста чем отличается менеджер по качеству от директора по качеству. какие обязанности у директора по качеству?

спасибо

Здравствуйте, Dummy, Вы писали:

D> объясните пожалуйста чем отличается менеджер по качеству от директора
D> по качеству. какие обязанности у директора по качеству?

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

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

Или ставим?

Здравствуйте, speedballer, Вы писали:

S>Здравствуйте, Dummy, Вы писали:

D>> объясните пожалуйста чем отличается менеджер по качеству от директора
D>> по качеству. какие обязанности у директора по качеству?

S>Полагаю, что директор по качеству (если таковой имеется) определяет политику компании в области качества, разрабатывает, внедряет и сопровождает процессы, связанные с обеспечением качества, в рамках компании в целом. Руководит (непосредственно или методологически) менеджерами по качеству.

S>Это, конечно, очень общо — но мы же не ставим себе целью здесь разработать должностную инструкцию конкретного директора по качеству конкретной компании.

S>Или ставим?

спасибо, понятно, почему то раньше думал, что всем этим занимается QA Manager

Здравствуйте, cvoronin, Вы писали:

S>>В проекте должны использоваться все роли, но один человек может сочетать в себе несколько ролей. По RUP не помню, но практика показала, что не все роли могут сочетаться безболезненно в одном человеке. Примером может служить плохое сочетание программиста-кодера и тестировщика.

C>Что любопытно, в XP приветствуется написание и прогон тестов программистом-кодером

Это так, но в таком случае (по XP) теста программист должен написать раньше чем начнет кодировать...

Здравствуйте, trial, Вы писали:

T>Не знаю, что говорит теория, и где берутся такие примеры, но вот практика показывает, что такое сочетание далеко не всегда плохое.
T>Мне лично, уже не один раз приходилось руководить тестированием именно программистами — из-за того, что тестеров в данный момент не было или надо было проверить качество их тестирования.
T>И выходило это — очень хорошо. Во многом — гораздо продуктивнее тестеров.
T>Отчасти, это происходило потому что мы лучше ориентируемся в логах нашего продукта — и как следствие можем находить "скрытые" баги — т.е. те, у которых нет моментального проявления на "зрительном" уровне.
T>Но ИМХО основная причина всё же в том, что у некого "среднего" программиста квалификация (общекомпьютерная, что ли) выше, чем у некого "среднего" тестера.
T>Я отнють не говорю, что это классно, правильно и т.д. тестирование силами программистов, как минимум — невыгодно фирме, т.к. получается, что разработчики за свою з/п занимаются трудом, за который обычно платят меньше.
T>Я лишь утверждаю, что при грамотном подходе используя программистов в качестве тестров можно очень многого добиться.

Граматные программисты умеющие и понимающие важность качественного тестирования легко могут протестировать свою разработку, куда лучше чем тестеры.
Однако подход к тестерам как к людям менее грамотным чем программисты — пагубный. Уровень знаний программиста и тестера не должен сильно различатся. Мало того, в крупных западных компаниях з/п программиста и тестера отличаются минимально. А кстати, вы сами пробовали когда-нибудь провести качественное тестирование продукта, да не для заказного, а для коробочного, когда тесты необходимо делать перед каждым релизом? Это безумно сложная задача? Необходимо владеть рядом инструментов для автоматизации, составлять планы тестирования, проверять результаты тестов...
Резюме: Тестер должен быть не менее квалифицирован чем разработчик, а так как разработчики на вес золота, то они иногда должны выполнять тестирование. Но главное не гнушаться этой работы, как делают большенство разработчиков, а подходить к ней как к одной из важнейших частей процесса разработки

Здравствуйте, NickSm, Вы писали:

NS>Граматные программисты умеющие и понимающие важность качественного тестирования легко могут протестировать свою разработку, куда лучше чем тестеры.

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

NS>Резюме: Тестер должен быть не менее квалифицирован чем разработчик, а так как разработчики на вес золота, то они иногда должны выполнять тестирование. Но главное не гнушаться этой работы, как делают большенство разработчиков, а подходить к ней как к одной из важнейших частей процесса разработки

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