Roman Susha
1517 сообщений
#13 лет назад
1
Быков Василь
339 сообщений
#13 лет назад
В принципе если договор есть - то его надо и следовать. Есть месяц гарантии - им надо пользоваться. Хотя другой вопрос что не все можно протестить за месяц, но в данном случае надо внимательнее относиться к договору.
Станислав Малкин
1410 сообщений
#13 лет назад
Самая большая ошибка менеджера - дать прямой контакт со своим сотрудником, запомните. Никогда не наступайте на эти грабли.
Вадим Т.
3240 сообщений
#13 лет назад
ArtLab, почему же, не согласен. Прямой контакт давать можно и нужно, причем всегда, когда есть такая возможность. Конечно, если сотрудники - свои, внутренние, не удаленники, и если они нормальные, вменяемые (с невменяемыми лучше вообще дела не иметь). Преимущество - значительная экономия своего времени, и времени менеджеров, если они есть в команде. Да и с заказчиком часто работать проще, меньше шансов что испорченный телефон получится.

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

Это относится к мелким проектам, до 200 человеко-часов. А вот более крупные проекты лучше пускать через тимлида-менеджера, так как программеры могут ротироваться внутри тима, лучше чтобы с заказчиком работал один и тот же handler на протяжении всего проекта. Но все равно прямые контакты программеров можно давать, особенно если проекты требуют коммуникации с программерами/админами со стороны заказчика.

Или я не прав?
Андрей Халецкий
3563 сообщения
#13 лет назад
tvv, думаю не совсем.
С преимуществами согласен, если все идет хорошо.

По недсотаткам:
1. программеры не отвечают за сроки перед заказчиком, по жтому они их не могут устанавливать. Хотя заказчик всегда просит сроков исполнения работы.
2. программеры одни из самых дорогих/нагруженных сотрудников, которые как правило не умеют работать с отвлечениями. Регулярное "дергание" заказчиком, плохо сказывается на производительности.
3. программеры не могут принимать решения о внесении изменений в требования (не отвечают за бюджет и сроки).


сейчас вытягивая список из программера, многие запросы "правок" по моему мнению чистой воды дополнения...
Тимур Шаммасов
1278 сообщений
#13 лет назад
Я считаю прямые контакты давать можно (а иногда и нужно).
Но четко проинструктировать своего програмиста о его сфере принятия решений. Т.Е, чтобы он всегда готов был ответить: "Это не мой вопрос, обратитесь пожалуйста к менеджеру. Ну а менеджеру в обязательном порядке, каждый день перечитывать всю переписку.
По поводу что делать дальше: Постараться добиться от заказчика п.1., Но быть готовым и к п.2.
Станислав Малкин
1410 сообщений
#13 лет назад
Цитата ("tvv"):
ArtLab, почему же, не согласен. Прямой контакт давать можно и нужно, причем всегда, когда есть такая возможность. Конечно, если сотрудники - свои, внутренние, не удаленники, и если они нормальные, вменяемые (с невменяемыми лучше вообще дела не иметь). Преимущество - значительная экономия своего времени, и времени менеджеров, если они есть в команде. Да и с заказчиком часто работать проще, меньше шансов что испорченный телефон получится.

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

Это относится к мелким проектам, до 200 человеко-часов. А вот более крупные проекты лучше пускать через тимлида-менеджера, так как программеры могут ротироваться внутри тима, лучше чтобы с заказчиком работал один и тот же handler на протяжении всего проекта. Но все равно прямые контакты программеров можно давать, особенно если проекты требуют коммуникации с программерами/админами со стороны заказчика.

Или я не прав?


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

Требовать с программиста ежедневного отчета (по общению с заказчиком) - тоже не совсем правильно - ничего не мешает программисту "схалявить" и в итоге менеджер будет опять не у дел. Это все не выходы.
Андрей Халецкий
3563 сообщения
#13 лет назад
То что заказчики не совсем порядочные и попытаются работать с программистами напрямую - пол беды. Гораздо хуже, что из-за общения замедляется работа и валяться проекты.

Найти человека который может "прикрыть" программера, не так дорого, как мириться с падением производительности.
Вадим Т.
3240 сообщений
#13 лет назад
Цитата ("ArtLab"):
Скажу по личному опыту - когда мне давали контакты прямые в фирмах, где я работал - когда я уходил из фирм - я этих клиентов уводил с собою. Вам нужны подобные вещи? Это как побочный эффект.
Требовать с программиста ежедневного отчета (по общению с заказчиком) - тоже не совсем правильно - ничего не мешает программисту "схалявить" и в итоге менеджер будет опять не у дел. Это все не выходы.

То что Вы уводили заказчиков - говорит о Вас не с лучшей стороны. Надеюсь, это в прошлом, и Вы так больше не поступаете сейчас с Вашими партнерами.

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

Далее, заказчиков и посредников предпочитаю долговременных, и таких, которые сами люди порядочные, и не поуводят программеров. То есть, даже если и попадется такая потенциальная крыса в коллективе, то ничего у нее не получится, заказчик или посредник мне же первому просигнализирует об этом. В общем, все это решаемо.
Вадим Т.
3240 сообщений
#13 лет назад
Цитата ("SmartDesign"):
Гораздо хуже, что из-за общения замедляется работа и валяться проекты.
Найти человека который может "прикрыть" программера, не так дорого, как мириться с падением производительности.

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

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

В общем, я предпочитаю развивать ребят с которыми работаю, многие вырастают и уходят, ничего не поделаешь, но отличные отношения остаются, и часто перерастают в партнерство (делимся проектами, заказчиками, подстраховываем друг друга периодически, меняемся опытом, просто проводим хорошо время, в конце концов), хотя уже у многих и разные команды-конторы-города-страны.
Андрей Халецкий
3563 сообщения
#13 лет назад
tvv, само собой, что толковые менеджеры стоят не меньше программеров, но если правило 1 программист на 1 проект следует выполнять, то 1 менеджер с легкостью может вести 3-5 проектов.

ЗЫ. Все же хотелось бы услышать комментарии автора темы.
Андрей Д.
1267 сообщений
#13 лет назад
Цитата ("tvv"):
В общем, я предпочитаю развивать ребят с которыми работаю, многие вырастают и уходят, ничего не поделаешь, но отличные отношения остаются, и часто перерастают в партнерство (делимся проектами, заказчиками, подстраховываем друг друга периодически, меняемся опытом, просто проводим хорошо время, в конце концов), хотя уже у многих и разные команды-конторы-города-страны.

Подобная ситуация, но если человек хороший, то он всегда с благодарностью относиться к тебе
Максимович Владимир
27 сообщений
#13 лет назад
Что сказать, много букв.....
Андрей, извени, но если бы ты не дал не каких контактов с программером, я бы не вытерпил, и тема бы была в плохом разделе. Через 2 дня после создания темы, стукнулся тот самый программист и начал исправлять свои ошибки. Вроде как исправит, сделаем тест, найдется баг, до сегодняшнего дня правили. Если тут пошли сроки об исправлении. Мы вобще заказывали нерабочий софт? щас занимаемся тестами и вот на данную минуту, мне некогда тестировать, у меня есть дела "важней" тестов.
А я сказал, что отпишу как будет получен готовый проект.
Bweb Bweb
316 сообщений
#13 лет назад
щас занимаемся тестами и вот на данную минуту, мне некогда тестировать, у меня есть дела "важней" тестов.
наймите тестера. Разработчику сидеть вас ждать? он проект возьмет другой и будет занят больше вашего.
Максимович Владимир
27 сообщений
#13 лет назад
Не надо писать софт с багами если на то пошло или пусть тестируют сами

BeautyWeb, вы умные чтоли такие?


как освободились, получили в ответ
(02:29:24 7/08/2007)
JazzCat (23:28:55 6/08/2007)
ок завтра с утра починю

если продолжить лог дальше, - это не будет наруку smartdesign
Вадим Т.
3240 сообщений
#13 лет назад
Цитата ("BeautyWeb"):
наймите тестера. Разработчику сидеть вас ждать? он проект возьмет другой и будет занят больше вашего.

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

Я например всегда включаю в смету пункт "QA", куда добавляю 15-40% от стоимость проекта, в зависимости от требований. И если заказчик этот пункт вычеркивает, вот тогда с ним уже утрясаю вопрос кто занимается тестированием и оплачивает человеко-часы, потраченные на это. Часто заказчик, экономя деньги, берет тестирование на себя, отсылая багрепорты в течении заданного времени.

А как договаривались заказчик и исполнитель в этом проекте, и договаривались ли вообще на эту тему, я не знаю.
Андрей Халецкий
3563 сообщения
#13 лет назад
tvv, вы абсолютно правы
Это разработчику нужно нанять тестера, чтобы минимизировать количество дефектов на выходе. Ведь он подвязался сдать рабочий проект, согласны? То есть, если вопрос тестирования заранее не оговаривался, то обычно подразумевается, что это бремя лежит на разработчике.
к сожалению, заказчик не может предоставить материалы для самостоятельного тестирования (прокси и траффик), ни доступа к серверу, по этому все приходиться делать через его администратора. То что могло быть проверено — работало при сдаче.

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

Если такой договоренности нет, обычно "бесплатный саппорт" действует только до того момента, как заказчик принял релиз. Вот тут-то и начинаются проблемы... Заказчик (даже если он и честный, хотя и кидалы таким способом пользуются) хочет подстраховаться, все проверить многократно, и как только может честными и нечестными способами оттягивает финальный платеж. Я такой случай в статье https://www.weblancer.net/articles/5.html "Фриланс. Минимизация рисков." выделил:

Риск фрилансера 2.

Задержка с оплатой. Это изначально не видится как надувательство, ведь в этом случае заказчик не отказывается платить. Но при этом все время оттягивает платеж, мотивируя например тем, что нужно систему протестировать и выявить возможные дефекты. Конечно, дефекты всегда находятся или придумываются, и эта задержка может тянуться неделями и месяцами.

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

Конечно, в данном случае, который описан на этой теме форума, заказчик вряд ли виноват, это наверное исполнителя проблемы, но на будущее - такие вещи всегда нужно учитывать и предусматривать/оговаривать заранее. Это несложно.
Андрей Халецкий
3563 сообщения
#13 лет назад
tvv, это не совсем тот случай (я бы даже сказал совсем не тот).
Проект сдан 2 месяца назад, оплата получена.

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

В нашем случае идет бесплатная поддержка.
Вадим Т.
3240 сообщений
#13 лет назад
А, ну да, если так, то согласен. Так и есть.