TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Ask HN: How do you work on tech specs?

3 点作者 pawelmor将近 2 年前
Hi,<p>I recently joined a new company where things are kind of disorganized. When working on new features, people just create a ticket without description and start working on it the same day.<p>I would like to suggest a better process to write technical specifications when needed especially on cross repo &#x2F; large scope projects. In my previous company, the tech specs were just files that got lost on a GDrive … How do you handle specs? Any tools I could suggest to my team? How to encourage people to read and contribute to specs files?

1 comment

maerF0x0将近 2 年前
I have a few ideas that can help, but won&#x27;t prescribe a tool (use what works in the context you&#x27;re in, likely what the company already has&#x2F;uses) ... In no particular order:<p>1. If the feature will require more than a day&#x27;s estimated work, think about how you can divide the effort into single day blocks. I often actually try to divide my work to even half day blocks because that helps my focus and keeps me shipping frequently. Often this means shipping a demoable, but not customer viable, feature (eg 1. you can curl an endpoint and it returns dummy data, 2. you curl the endpoint and it rejects invalid data 3. you curl the end point and it saves to the db.) . Often it&#x27;s an improvement to simply break up the CRUD steps into separate efforts.<p>2. Think like a QA and lay out some limits on each aspect of the feature, how many chars in each field, what characters are allow (ie a phone number shouldnt have an emoji), which things must be enums, unique, or equal to some other value?<p>3. Think about scale, what is the present and projected scale (you have to use your context to choose a timeline that matters. In a startup that might be 6 months, in a established business I&#x27;d try to think about 1 yr and 3 yrs). Try to find a solution that is sufficient for today, but leaves the easiest scale option to the longer trend open. To be clear I&#x27;m not saying implement the solution to the long term need. An example could be &quot;today we&#x27;ll deploy containerized onto Lamba, in the long run when we need more scale or lower costs we can do an EKS cluster&quot;<p>4. Solicit feedback from peers and adjacent teams who might interface with the system.<p>5. I try to lay out rough schemas like the fields required, json, SQL schema etc just to get a sense of what questions I want to ask the product designer. Mostly this is just to make my self familiar with what I want to build, less about waterfalling and locking in a contractual design that cannot be changed.<p>Edit: as for getting people to care? Thats a culture thing, and in my experience culture can only come from leadership. Perhaps it&#x27;s quite possible to influence widely as a IC but i&#x27;ve never been able to pull it off, and rarely seen it pulled off, and only in a limited magnitude.
评论 #36115289 未加载