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

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

Кто из нас не ронял продакшн, не обнаруживал, что база побилась, а бэкапов нет, не обваливал работу системы перед демо коммитом «ну сейчас рюшечку поправлю только, она же точно ничего не поломает», не выкатывал на всю аудиторию мобильное приложение со 100%-воспроизводящимся критичным багом, не обнаруживал продакшн-сервер взломанным, да мало ли бывает замечательных действий… Некомфортная ситуация влияет на наше состояние, не дает принимать взвешенные решения, заставляет поступать так, как в спокойной обстановке мы бы не поступили — только диву даешься, как же вот этого не увидел или вот этого не сделал. И хочется разобраться, что же происходит, понять, как лучше в следующий раз и вообще научиться с ним справляться. Как? В статье мы с AlbinoKoala систематизировали свой опыт и даже прочитали митап перед коллегами.

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